Site system roles are SMS roles — such as a logon point, a client access point (CAP), and an SMS site database server — that can all be assigned to the site server or to other computers within your SMS site hierarchy.
Assigning some site system roles in SMS requires careful planning. For example, the SMS site database server, CAP, distribution point, and software metering server roles require special consideration as you begin to plan hardware requirements. These considerations are described in the following sections.
SMS depends on SQL Server as its database engine. The database device configuration of SQL Server and the resource needs of SMS are linked and have hardware interdependencies. The performance of SMS is directly related to the performance of SQL Server. As a minimum, you must be sure to provide adequate resources for both applications. To do so, you need a clear understanding of how these two applications work together.
SMS will achieve maximum performance when the installation of SQL Server is designated for SMS only. You can also significantly increase the performance of SMS if the SMS site database is installed on the same computer that performs the SMS site server role, if that computer has enough processing power to accommodate both applications. If you are using SQL Server for other applications within your organization, you must decide whether to use a remote installation of SQL Server. Running SQL Server on a computer that is not the site server will only benefit your site if you are using SQL Server for other applications within your organization.
Disk I/O is the largest mitigating factor. Installing the data devices and log devices onto separate physical drives or RAID arrays will improve the disk performance of SQL Server and indirectly benefit the performance of SMS.
SMS and SQL Server communicate constantly, so if you must have SQL Server installed on a remote computer, you need to carefully inspect the intervening network connection. The speed of the connection between these two applications will greatly affect their performance. If SQL Server seems to be under-optimized and resolving disk I/O problems does not improve performance, the likely problem is a slow connection between the two applications. Even though SQL Server and the SMS site server each has its own processor and disk structure, a slow connection between them can hinder performance.
You can determine the amount of data written to the SMS site database by reviewing the number of clients in your site and overall usage patterns, such as the flow of status messages, hardware and software inventory records, and DDRs into your site database. The total amount of data that SMS writes to the SMS site database can dramatically change the hardware required to optimize SQL Server performance. Often, if a large amount of data is written to the SMS site database at one time in the month, or if network database usage is high during any particular part of the day and you are not enabling many SMS features that require SQL Server processing, you will need less processor power and disk space for SQL Server alone.
SQL Server uses memory for extensive caching. The more memory that you can provide SQL Server, the more it will use and the faster it will run. For more information about tuning the SQL Server memory cache, see “Tuning” in the SQL Server Resource Guide, in the Microsoft BackOffice Resource Kit, Part 2.
Another issue to consider when determining SQL Server and SMS hardware requirements is the total amount of data that is likely to accumulate in the SMS site database. If you have an accurate and complete picture of your network before you run your pilot project, you can begin to estimate the amount of data that will accumulate and the size of the database required to store it. If your network structure is changing or is very complicated, you might need to run the pilot project before you can accurately evaluate hardware requirements for the SMS site database.
To estimate the required SMS site database size for a single site, use the following formula as a baseline:
7.4 MB + x * 70 KB (where x is the number of clients in the site)
This formula is based on the following Express Setup default settings:
The formula also allows for 20 status messages per client, per week.
The algorithm used by SMS 2.0 Setup allows 100 KB per client with a minimum SMS site database size of 50 MB.
A client access point (CAP) processes the objects created by SMS client activity. Because it hosts the installation of the majority of client components, a CAP will often be loaded heavily during the SMS deployment process. After SMS is deployed, a CAP is primarily responsible for relaying the majority of the objects sent from clients to the site server. The following SMS components create a load on a CAP:
CAPs also contain files that your clients check for new advertisements and configuration changes. This means that you must be prepared for a potentially large number of clients accessing the CAP. Be sure that you have enough CAPs to support the clients in a site, and that you have enough client access licenses on your CAPs to support these loads. Also, if your clients use Novell NetWare, you need to configure at least one NetWare server to perform the CAP role in a site.
For better performance and availability, consider configuring more than one CAP in a site. For example, having one CAP for each network segment will reduce the load on routers between segments.
If you make configuration changes to an SMS site (for example, if you enable Remote Control when it had previously been disabled), and the site contains a large number of clients, the clients will all contact the CAPs at their next wakeup interval (the default interval is 23 hours) and install this component from the CAPs. Therefore, even though your CAPs might not be heavily loaded all the time, you need to make sure that you have enough capacity to perform these operations after your site hierarchy is set up. To assist with load balancing, you can customize how clients contact CAPs. For information about how to set a preferred CAP for a client, see the “Set Preferred Distribution Point and CAP Tool (PrefServ.exe)” section in Chapter 13, “Using SMS 2.0 Tools — Part 1.”
A distribution points is where SMS places software distribution packages. Clients access a distribution point for the files needed to run advertised programs. The load on a distribution point will vary with the number and size of the packages you distribute. You need to size distribution points just as you would size any file servers in your organization. Also, if your clients use NetWare, you need to configure at least one NetWare server to perform the distribution point role in a site.
For better performance and availability, consider configuring more than one distribution point in a site. For example, having one distribution point for each network segment will reduce the load on routers in between segments.
You can control the load on distribution points by carefully scheduling software distribution. For example, if you are rolling out Windows NT Server 4.0, Service Pack 4 to your organization, you might want to spread the load across time by creating several small assignments targeted to different collections at measured intervals throughout the night. Alternatively, you could roll out Windows NT Server 4.0, Service Pack 4 to every client at one time, but spread the load across multiple distribution points. You can set preferred distribution points for clients. For information about how to set a preferred distribution point group for a client, see the “Set Preferred Distribution Point and CAP Tool (PrefServ.exe)” section in Chapter 13, “Using SMS 2.0 Tools — Part 1.”
A software metering server is a site system that performs server-side software metering tasks, such as responding to client requests for licenses. If you plan to use SMS software metering functionality at your site, you must specify one or more software metering servers.
To determine the number of software metering servers you need to be able to support software metering in your site, observe the network traffic created by user logon and application launch and shutdown. For example, if your organization has rigidly scheduled work times, you are likely to see clear peaks in user logon and application launch traffic at the start of the work day, a decrease in activity around lunch time, a more gradual peak in the afternoon, and a final peak at the close of the business day as applications are shut down. If your organization has very flexible work schedules, you might not see clear peaks.
Software metering clients can be configured to operate in one of two modes: online or offline. When planning for software metering server requirements, it is important to understand which mode your site will use.
If you configure SMS clients to run in online mode, the Software Metering Client Agent contacts a software metering server whenever a user starts or stops an application. Online mode enables you to control software usage through permissions or license availability. In online metering mode, you must provide sufficient capacity of software metering servers to respond in real time to the peaks you charted.
If you set the online mode, consider the following ramifications:
The key to measuring software metering capacity requirements is to estimate the number of application launches and shutdowns over a known period (per hour, day, or week). For example, if 120 clients will each run two metered applications and they will all start and stop the applications during the same hour, that is equivalent to 480 metering events per hour.
If you configure your SMS clients to run in the passive offline mode, the Software Metering Client Agent sends usage data to a software metering server on a periodic schedule. License balancing between software metering servers is not required, and offline mode results in a reduced volume of network traffic generated by software metering components. You can still deny access to a specific application, and you can measure the usage of metered applications.
In offline mode, the software metering server capacity must be sufficient to process a backlog of metering usage information in a timely manner, with no backlog longer than a given period (for example, one week).
The client agent will report that all metered applications that are active at the beginning of a polling interval were actually started at the beginning of the polling interval. Also, all metered applications that are active at the end of a polling interval are reported to be shutdown at the end of the polling interval (and restarted at the beginning of the next period). Reducing this polling interval to a small value, such as one minute, will simulate a large number of application launches and shutdowns in a short period of time allowing a large simulated load on a software metering server.
You can accurately estimate the number of software metering servers required by modeling the traffic generated by application launch activity by setting the Configuration polling interval to one minute during your pilot project. For example, to simulate the traffic of 480 application events per hour, you could configure four clients in the pilot project and start the two metered applications on each. Or, configure two clients and four metered applications.