The Deployment Process
| This section outlines the general procedure for deploying a SQL-NS instance. This is not intended to be a definitive, step-by-step set of instructions but rather a high-level walk-through of the stages in the deployment process. The exact sequence of steps you need to follow when deploying your SQL-NS instance depends on the deployment configuration you've chosen, the hardware you're using, the applications in your SQL-NS instance, and the components they employ. Note The information in this section assumes that the machines you will use in your deployment have already been configured with the appropriate hardware and operating system software. It also assumes that your SQL Server database engine is installed and ready for use. Installing SQL-NS on the Deployment MachinesThe section "Installing Notification Services and Other SQL Server 2005 Components" (p. 27) in Chapter 2 provides instructions on installing SQL Server 2005 components, including SQL-NS. You will need to install SQL-NS components on the machines in your deployment that host the SQL-NS engine or other programs that use the SQL-NS API (such as the SMI or standalone event providers). You use SQL Server 2005 setup to do this. When you run SQL Server 2005 setup, you are given a choice of components to install. One of the options is Notification Services. If you choose this option, all the components of SQL-NS are installed. However, not every SQL-NS component is needed on every machine in your deployement, so a better strategy is to install components of SQL-NS selectively instead. To do this, check the Notification Services option in the Components to Install dialog box, but then click the Advanced button before proceeding to the next step in the setup wizard. In the Feature Selection dialog box that opens, expand the Notification Services item in the feature tree. Beneath this item are two choices: Engine Components and Client Components. You can choose to install either one, or both. As the name suggests, Engine Components includes everything required to run the SQL-NS engine. A SQL Server license is required for every machine on which the SQL-NS Engine Components are installed. The Client Components include only the features required to run SQL-NS client programs, such as SMIs and standalone event providers. A SQL Server license is not required for machines on which only the SQL-NS Client Components are installed. Caution Before you begin your deployment, make sure you have the required licenses to install SQL-NS on all your deployment machines. For more information on licensing, consult the SQL-NS licensing FAQ at http://www.microsoft.com/sql/technologies/notification/nslicensingfaq.mspx. Tip Instead of using SQL Server 2005 setup, you can use the SQL-NS Redistributable Package to install the SQL-NS Client Components. The Redistributable Package includes only the SQL-NS Client Components. If you need to install the SQL-NS Engine Components, you must use SQL Server 2005 setup. The SQL-NS Redistributable Package can be downloaded from http://go.microsoft.com/fwlink/?LinkId=54583 (search for "Microsoft SQL Server 2005 Notification Services Client Components"). In your deployment, you can selectively install SQL-NS components as follows:
However, if a single machine serves more than one function (such as hosting the SQL-NS engine and the SMI), you should install the components required for both functions on that machine. In the simplest single machine deployment, you can install all the SQL-NS components at once. Specifying the Server Configuration in the ICF and ADFsThe ICF declares the name of the SQL Server to host the instance's databases, and the ADFs declare the machines on which the event providers, generator, and distributors will run. After you've decided on a particular server configuration for your deployment, you need to edit these declarations in the ICF and ADFs to ensure that they properly reflect the chosen configuration. The SQL Server name is specified in the <SqlServerSystem> element of the ICF. The value specified should match the name of your deployment SQL Server. The host machines for the other components are specified via the <SystemName> element in the <HostedProvider>, <Generator>, and <Distributor> declarations in the ADFs. The <SystemName> values should reflect the names of the machines on which the components should run. Note On SQL-NS Standard Edition, specifying different <SystemName> values for different components in the same application results in a compile error. SQL-NS Standard Edition requires that all components run on the same machine, so the <SystemName> values must be the same. Tip <SystemName> elements in the ADF can specify either NetBIOS names or fully qualified domain names. If you intend to run multiple distributors to scale out notification formatting and delivery (as shown in Figure 13.4), your ADF will need multiple <Distributor> declarations. In development, you probably used only a single distributor, so you may need to add new <Distributor> declarations to your ADF (one for each distributor in your deployment). The <SystemName> element in each <Distributor> declaration should specify the name of the appropriate host machine. Recall that you may configure only one distributor on any one machine. Tip It's a good idea to use parameters to specify machine names in the ICF and ADFs. This allows you to change the machine configuration without having to edit the declarations in these files. All the examples shown in this book specify machine names using parameters. Deploying Custom ComponentsIf your applications use custom components (custom event providers, content formatters, or delivery protocols), you need to copy the assemblies containing those components to the deployment machines on which they will be hosted. After you've copied the assemblies over, you will likely need to update the ICF and ADFs to ensure that the assembly locations are correctly specified. The full paths to the custom event provider, content formatter, and delivery protocol assemblies are specified in the <AssemblyName> elements of their respective declarations in the ICF and ADF. In the development environment, these paths probably pointed to the directories in which the assemblies were originally built. After you move the assemblies to the deployment machines, you may need to change these paths to reflect their new locations. Tip If you use strong names for the assemblies, you may need to install them in the Global Assembly Cache (GAC) on the deployment machines. Creating the Instance and Application DatabasesThe procedure for creating the instance and application databases in deployment is the same as in development. After you have your ICF and ADFs ready to compile, you invoke the SQL-NS compiler, either through Management Studio or nscontrol create. The instance and application database objects will be created in databases on the SQL Server identified in the <SqlServerSystem> element in the ICF (which should be your deployment server). The creation process may take longer than it did in the development environment if the SQL-NS compiler needs to create databases and you specified large initial sizes for these databases' physical files. After the creation process completes, you should verify that the physical files have been created in the locations you expect. Registering the Instance on All Deployment ServersRegistering an instance creates Registry keys used by the SQL-NS engine, and the SQL-NS API, to locate the instance and application database objects. In the process of registering, you can also install the SQL-NS Windows service and configure it to run under a specific account. In your deployment environment, you need to register the instance on all machines that host the SQL-NS engine or programs, such as SMIs and standalone event providers, that use the SQL-NS API. You can register the instance using either the Register Instance command in Management Studio or the nscontrol register command-line tool. If you use the nscontrol register command, be sure to specify the name of the deployment SQL Server in the -server argument. Caution It's a common mistake to specify the local server name instead of the SQL Server name in the -server argument to nscontrol register. Always be sure that the -server argument specifies the name of your deployment SQL Server. On machines that will run the SQL-NS Windows service, you should install the service when registering the instance. From Management Studio, you do this by checking the Create Windows Service box in the Register Instance dialog box. If you're using the nscontrol register command, you pass the -service argument to install the service for the instance. You need to specify the Windows username and password of the service account (and the SQL username and password if you are using SQL Server Authentication). Also, don't forget to specify the argument key if you are using argument encryption. On the machines hosting only the SMI or standalone event providers (and not the SQL-NS Windows service), you can register the instance without installing the service. This creates just the required Registry keys and performance counters. Granting Database Permissions to Deployment AccountsAll the accounts you use to run components in your SQL-NS deployment need permission to log in to your SQL Server and access the SQL-NS databases in the various SQL-NS roles. The procedure for granting the required database access is similar to that used in development, except that you may have to apply it to more accounts, and the roles that you use may be more specific. The "Granting Permissions" section (p. 92) in Chapter 4 provides details on the process of granting permissions. Granting Filesystem Permissions to Deployment AccountsIf you use components that access files, you need to grant the appropriate filesystem permissions to the accounts under which those components run. The FileSystemWatcher event provider and the File delivery protocol are examples of components that require filesystem access. Although it's unlikely that you will use these components in a deployed SQL-NS application, you may have custom components that require filesystem access. In keeping with the general security principle that accounts should be granted only the minimum required permissions, you should grant filesystem access selectively. Components should be allowed access only to the specific parts of the filesystem required for their operation. If an intruder is able to exploit a component to gain unauthorized access to your system, their access to the filesystem should be as limited as possible. Deploying the Subscription Management Interface and Standalone Event ProvidersSMIs and standalone event providers are really independent programs loosely coupled to the core SQL-NS application. Because SQL-NS does not place many restrictions on the nature and form of these programs, there are no SQL-NS specific instructions for deploying them. As long as the SQL-NS instance is registered on the machines hosting the SMI and standalone event providers, you can deploy them using whatever procedures you normally use to deploy independent programs in your production environment. Enabling a Deployed InstanceAfter the instance has been created and registered and all required components deployed, you need to enable it before it can run. As in the development environment, you enable the instance using the nscontrol enable command or using Management Studio. The "Enabling the Instance" section (p. 95) in Chapter 4 provides details on the commands used to enable instances. In the examples in this book, the enable commands are always used to enable the whole instance. However, you can also specify particular components of the instance to enable. This allows you to selectively enable only parts of the instance, while leaving others disabled. For more information on enabling or disabling specific components, see the "Enabling and Disabling Components" section (p. 492) in Chapter 14. Starting the InstanceTo start the instance, you need to start the SQL-NS engine on every deployment machine that hosts engine components. If the engine runs as a Windows service, you can use Management Studio to start the service on all the required machines. To do this, right-click the instance in the Notification Services folder of Management Studio's Object Explorer and choose Start from the context menu. Management Studio determines which machines host the service (from the machine configuration specified in the ADF) and starts the service on all those machines remotely. Unfortunately, SQL-NS does not provide an equivalent command-line tool you can use to start the service on all the required machines. If you're working from the command line, you have to start the service on each machine manually, using the net start command. If all the services start successfully, you know you have a running instance. Getting your SQL-NS instance running in the deployment environment for the first time is an important achievement! Although you may experience a few minor operational problems in the first days after the application is rolled out, seeing your applications in operation should be a satisfying experience.
|
EAN: 2147483647
Pages: 166