Deployment Configurations

The components of a SQL-NS instance (the database, the SQL-NS engine, the SMI, and standalone event providers) can be deployed in several ways, on one or more servers. The section "Deployment of SQL-NS Instances on Multiple Servers" (p. 102) in Chapter 4, "Working with SQL-NS Instances," provides a brief overview of various multiserver deployment configurations. This section provides more detail on the supported configurations and describes the advantages of each. The particular one that is appropriate for your SQL-NS instance depends on the hardware resources available to you and the performance and reliability requirements of your applications.

Note

The terms server and machine are used interchangeably in this chapter. Both terms refer to a computer in a deployment environment.

The intent of this section is to illustrate the topology of the various deployment configurations (the layout of the machines involved and the functions performed by each). This section does not cover the configuration settings or deployment steps required to implement these configurations. That information is provided in the subsequent sections of this chapter.

Note

This section, and the rest of this chapter, covers deployment of only the server-side components of a SQL-NS instance. If your SQL-NS instance has client-side components (such as programs that serve as SMIs or standalone event providers), they will need to be deployed like any other client program.

Single Machine Deployment

This simplest deployment of a SQL-NS instance is one in which all the components are hosted on a single machine. This may be the configuration in which you've been running your SQL-NS instance during development. Figure 13.1 illustrates a single machine deployment.

Figure 13.1. A single machine deployment of a SQL-NS instance.

The simplicity of a single machine deployment has definite advantages: There is only one machine to administer, communication between components does not generate network traffic, and it's easy to move the instance to another machine if the need arises. However, there are some drawbacks as well. First, a single machine deployment is limited in its capacity to scale because all components on the machine share a common set of resources (disk, memory, CPU, and so on). More importantly, a single machine deployment can present a security risk. If one component becomes compromised and allows an unauthorized user to gain control of the machine, that user will have access to all the other components as well.

If your applications have only modest scale requirements, and you are comfortable with the security limitations, a single machine deployment may be appropriate. To implement a single machine deployment, you will need to install SQL Server, SQL-NS, and any components required to run your SMI (such as Internet Information Server [IIS] in the case of a web-based SMI) on the deployment server. You then follow the same steps used in the development process to create, register, and configure the SQL-NS instance.

Separating the Database Server

A common deployment configuration, used in the vast majority of SQL-NS applications, is to separate the SQL Server from the rest of the components of the SQL-NS instance. In this configuration, SQL Server is hosted on one machine, and all the other components are hosted on another machine. The databases associated with the SQL-NS instance and applications reside on the SQL Server machine. Figure 13.2 shows this deployment configuration.

Figure 13.2. A deployment of a SQL-NS instance with the SQL Server on a separate machine.

Caution

When you separate the SQL-NS engine from the SQL Server as shown in Figure 13.2, the original SQL Server license no longer covers the SQL-NS engine. You will need an additional SQL Server license for the machine hosting the SQL-NS engine.

This configuration has the advantage of providing dedicated hardware to the SQL Server. The SQL Server machine can be fitted with high-performance hardware, such as RAID disk systems, fast networking, and lots of memory, and be tuned for maximum performance. The isolation of the SQL Server from the rest of the system is also desirable from management and security standpoints.

Note

This configuration is commonly used when the SQL Server is shared between the SQL-NS instance and other, unrelated applications that require a database.

As mentioned earlier in Chapter 4, the separate database deployment configuration is well suited to the way most SQL-NS applications work. Typically, a running application does about half its work in the database (updating chronicles and matching events with subscriptions) and half its work in the SQL-NS engine (submitting events and distributing notifications). The split of these two halves of the application processing onto separate machines provides dedicated resources for each.

To implement the separate database deployment, you install SQL Server on one machine (or use an existing SQL Server installation). On another machine, you install SQL-NS and any other required components, the same as you would if you were doing a single machine deployment. When you create the SQL-NS instance, you specify the name of the remote SQL Server. The SQL-NS compiler then constructs the instance and application database objects on this server. On the machine hosting the other components of the instance, you need to register the instance and install the SQL-NS engine. When you register the instance, you again specify the name of the remote SQL Server. The register command records the remote SQL Server name in the local Registry so that the engine can locate the instance and application database objects at runtime.

Scaling the SQL Server: Providing More Generator Horsepower

Because the majority of the generator's work is done in the database (it spends most of its time running chronicle and match rule queries), you can improve generator performance by deploying your SQL Server on a high-scale system. Generally, two strategies are used to increase the capacity of a SQL Server: scale up and scale out. Scaling up involves increasing the power of the machine on which the SQL Server runs. This can be done by adding more processors and using high-performance memory and disk systems.

Note

The generator component in the SQL-NS engine is just a coordinator for database activities and does not require many resources. Therefore, generator performance is largely unaffected by increasing the power of the system on which the SQL-NS engine runs.

In contrast to scaling up, scaling out involves partitioning the database over several separate SQL Servers. The database workload is shared among these SQL Servers, with each one handling a distinct portion of the total data. SQL-NS does not provide any direct support for partitioning, and it is generally difficult to implement partitioning of the SQL-NS database objects on your own. For this reason, it is recommended that you follow a scale up, rather than scale out, strategy for adding more power to your SQL Server.

Note

You can implement one simple form of partitioning fairly easily: just create two (or more) identical SQL-NS instances on various servers. Each one can handle a discrete subset of the subscriber base, and together they share the total workload. In such a system, the SMI directs each new subscription to one of the duplicate instances, according to some criteria. The event providers fan out events to all the SQL-NS instances. This strategy does provide scale out, but multiplies the administration and maintenance overhead.

The "Scalability and Very Large Database (VLDB) Resources" page (http://www.microsoft.com/sql/techinfo/administration/2000/scalability.asp) on Microsoft's website provides detailed information on scaling SQL Server.

Separating SMIs and Standalone Event Providers

If your SQL-NS applications have web-based SMIs, you need a web server to host them. In the deployment configurations we've looked at so far, the SMI web server runs on the same machine as the rest of the SQL-NS components, but it can also be separated onto its own machine.

The same arguments that justify separating the database from the rest of the SQL-NS instance also apply to separating the web server. It makes management easier (especially when the web server hosts multiple web applications) and provides security advantages. Also, if the web server is on a dedicated machine, that machine's hardware can be tuned and optimized to meet the particular performance needs of the web server.

Web servers are exposed to the Internet and therefore are often deployed outside the firewall that protects the rest of the infrastructure. Using a separate machine for the web server allows you to place it outside the firewall without worrying about exposing the rest of the SQL-NS instance to unauthorized users.

Standalone event providers may also communicate with Internet event sources (via either a push or a pull model), so they may also need to be outside the firewall. You can usually host these on the same machine as the web server. Figure 13.3 shows a deployment in which the SMI and standalone event providers have been separated onto a dedicated machine.

Figure 13.3. Using a dedicated machine to host the SMI and standalone event providers.

Note

The single machine hosting the SMI web server depicted in Figure 13.3 can be replaced by a cluster or a server farm to increase the capacity of the SMI.

To implement a SQL-NS deployment with the web server and standalone event providers on a separate machine, you follow the same basic procedure used for the separate database deployment. However, you install the SMI and standalone event providers on their own machine rather than the machine hosting the SQL-NS engine. On the SMI machine, you must also install the SQL-NS Client components and register the instance.

Caution

If only the SQL-NS Client componentsthat is, not the SQL-NS Engine componentsare installed on a machine, a separate SQL Server license is not required. In the deployment depicted in Figure 13.3, SQL Server licenses would be required only for machines 1 and 3. The section, "Installing SQL-NS on the Deployment Machines" (p. 476), later in this chapter, provides instructions on installing only the SQL-NS Client components.

Scaling Out the SQL-NS Engine

In all the deployment configurations looked at so far, the SQL-NS engine runs on just one machine. The hosted event providers, generators, and distributors of the applications in the instance run in the engine, on that one machine.

SQL-NS supports separating the components that run in the engine onto separate machines. This enables scale out of the functions of the SQL-NS pipeline. Each machine runs its own copy of the SQL-NS engine (usually, a copy of the SQL-NS Windows service), hosting a subset of all the components. For example, the engine on one machine may host the event providers and generator, and the engine on another machine may host the distributor. Although the components may run on different machines, they are still considered part of a single SQL-NS instance.

Note

Only SQL-NS Enterprise Edition supports running the components of the engine on different machines. If you're using SQL-NS Standard Edition, the hosted event providers, generators, and distributors in an instance must all run on a single machine.

Although SQL-NS allows you to configure the components across machines in any combination you choose, in practice, the most common configuration has the hosted event providers and generator on one machine and the distributor on a separate machine. In most applications, the event providers and the generator component in the engine (which, as mentioned earlier in this chapter, are a coordinator for the generator's database activity) require the least resources. However, the distributor can often be a performance bottleneck, so separating it onto a dedicated machine can offer performance advantages if that machine is tailored to the distributor's particular needs.

For even more scale on the distribution end, an application can have multiple distributors and run each one on a dedicated machine. These machines then share the distribution workload of the application. Figure 13.4 shows this configuration. As described in the "Using Multiple Distributors" sidebar (p. 308) in Chapter 9, "Content Formatters," using multiple distributors in a single application makes sense (and is allowed) only if they are hosted on separate machines.

Figure 13.4. Separating the components of the SQL-NS engine onto separate machines.

Caution

Every machine hosting the SQL-NS engine must be covered by a valid SQL Server 2005 license. When planning a scale-out deployment of the SQL-NS engine, you must ensure that you have the correct licenses.

To implement a SQL-NS deployment with the components of the engine running on different machines, you need to change the <SystemName> values specified in the components' configurations in the ADF. The section "Specifying the Server Configuration in the ICF and ADFs" (p. 477) describes how to do this. On each machine hosting the engine, you need to install the SQL-NS Engine components (as described in the section "Installing SQL-NS on the Deployment Machines," p. 476, later in this chapter). You also need to register the instance on each of these machines.

High Availability

You can use failover clustering to ensure high availability in your SQL-NS deployment. Both the SQL Server and the SQL-NS engine can be hosted on failover clusters for maximum availability. For more information on configuring SQL Server for high availability, see the "High Availability Resources" page on Microsoft's SQL Server website at http://www.microsoft.com/sql/techinfo/administration/2000/availability.asp. For general Windows clustering information, see the "Clustering Services" web page at http://www.microsoft.com/windowsserver2003/technologies/clustering/default.mspx.

When using a failover cluster to host the SQL-NS engine, use the virtual server name of the cluster in any place that a machine name is expected in the ADF. Specifically, the <SystemName> elements in the component declarations should specify the cluster's virtual server name. For more information on using clustering with the SQL-NS service, see the "High-Availability Configurations" topic in the SQL-NS Books Online.