Determining Site Server Hardware Requirements
The hardware required for SMS site servers largely depends on the SMS features that you choose. When your business grows and changes, the SMS site server hardware requirements change accordingly. For the initial SMS deployment, you must develop initial hardware requirements that you can use to start the pilot project. To estimate hardware requirements for each SMS site server, determine the following:
The number of clients you plan to install and the number of SMS objects you expect to have at the site.
The load signature of installed SMS components.
It is important to build SMS site servers with as much fault-tolerant hardware as economically possible. Determine the load signatures of primary and secondary site servers, in addition to all other servers that are assigned SMS roles. After you have determined the load signature for the site component servers, you can establish initial hardware requirements.
The recommendations in this section are based on a number of factors, such as the number of clients and the number, size, and frequency of objects processed by SMS. Regardless of these recommendations, performance results might vary. Consider all the factors and carefully select server hardware based on all potential variables in your environment. Important factors include:
SMS features enabled:
Number of collections and their refresh schedule
Software distribution (frequency and size)
Software metering
Discovery methods used
Hardware and software inventory frequencies
Hardware and software inventory sizes
Reporting
Software Update Management
Available network capacity
Other applications sharing SMS server hardware
Number of clients in the SMS site
User community and acceptable performance through service level agreements
Budget constraints
Use the following guidelines when you develop your SMS site server sizing plan:
At small SMS sites, processor, memory, and disk resources are generally not big issues and are easier to track and maintain.
At medium SMS sites:
Memory must grow proportionately to the number of clients.
Disk I/O becomes a potential performance bottleneck; consider a RAID configuration.
Processor capacity requirements increase proportionately to the frequency of package distribution and inventory collection; consider dual processor servers.
At large SMS sites:
Memory must grow proportionately to the number of clients.
Disk I/O becomes a likely performance bottleneck; consider a RAID configuration such as RAID 1+0, and separate hardware volumes and channels for increased performance.
Processor capacity requirements increase proportionately to the frequency of package distribution and inventory collection; consider quad processor servers.
The hardware requirements you develop after reading these sections are for production purposes only. For the test lab and pilot project, these numbers might require adjustment, based on the fraction of the production environment included in the pilot deployment. For more information, see Chapter 10, "Planning Your SMS Deployment and Configuration."
Consider using SCSI RAID disk controllers
Hardware-based SCSI RAID controllers provide redundancy in the event of disk failure. Also, they can improve system performance when they are implemented. Many SCSI controllers provide read/write caches that can greatly reduce CPU usage during times of increased load. SCSI RAID controllers also spread read/write operations across multiple disks, and improve disk access times.
The following is a sample SCSI implementation plan for a site server:
Channel 1 - 4 volume RAID5 array for the SMS site database
Channel 1 - 2 volume RAID1 array for the Windows system files, the SQL Server master database, and the system's virtual memory paging file
Channel 2 - 6 volume RAID5 array for SMS
Channel 2 - 2 volume RAID1 array for the SMS SQL Server transaction log (write caching disabled)
Depending on a number of configuration factors, medium-sized primary sites (1,000-5,000 clients) and large primary sites (20,000-50,000 clients) might determine disk input/output (I/O) to be a bottleneck. For this reason, consider separating hardware volumes and channels for performance with a SCSI RAID controller.
The use of high-end SCSI controllers and disks is recommended for SMS site servers that are servicing a large number of clients and using many SMS features. However, budget limitations might prevent the feasibility of this. SMS works well on current integrated device electronic (IDE) disks. IDE disk subsystems are not as recoverable, but they can perform adequately.
In general, if you are in a medium to large organization, you should consider the following tips when you are building SMS site system hardware:
Place the SMS site server and SMS site database on different channels (if you are using SCSI hardware).
Neither the SMS site nor the SMS site database share their disks with other applications.
Configure the SQL Server transaction log to run on a different disk than the disk where the SMS site database is located.
On This Page
Estimating the Number of Clients and Objects
Developing Initial Hardware Requirements
Determining Site System Hardware Requirements
Determining SMS Site Database Server Requirements
Estimating the Number of Clients and Objects
The hardware requirements of SMS site systems depend on the number of objects that the site servers must process. Objects are items that are processed and stored in the SMS site database. SMS uses objects to move and store client and server data. Each SMS feature creates different types of objects. The following are the most common objects:
Discovery data records (DDRs), which are produced by discovery methods
Hardware inventory files: hardware inventory complete (.hid), hardware inventory delta (.hid), and Management Information Format (MIF) files
Software inventory files: software inventory complete (.sic) and software inventory delta (.sid)
Status variable files (.svf)
You can configure many SMS components to control the number of objects they produce. Table 9.6 lists common objects generated by SMS components.
Table 9.6 Objects Generated by SMS Components
Component |
Objects generated per interval |
|---|---|
Heartbeat Discovery |
1 DDR per heartbeat interval |
All other discovery methods |
1 DDR per object found |
Hardware inventory |
1 status message and 1 MIF file per inventory interval |
Software inventory |
1 status message and 1 .sic or .sid file per inventory interval |
Software distribution |
6 status messages (.svf) per new advertisement 2 status messages (.svf) per existing advertisement |
Software metering - Legacy Client |
1 rule file (.mux) and 1 status message for each cycle 1 status message for each usage report upload |
Software Metering - Advanced Client |
1 status message each time a software metering rule is added or deleted from its policy 1 status message for each usage report upload |
The initial hardware and software inventory on clients is a complete inventory. Subsequent inventories produce delta inventory files that contain only changes to configuration , are smaller, and process faster than a complete inventory. When you perform sizing tests, however, be sure to consider that SMS occasionally requests an inventory resynchronization. When this happens, all the clients in the site report full inventories during their next inventory collection cycle. The site can become overwhelmed in this peak situation if you are using network connections, or server hardware that can only maintain the flow of the smaller delta inventory. For more information about the resynchronization process, see Chapter 3, "Understanding SMS Features."
Table 9.7 offers another way to look at objects that are generated given a specific site configuration. The numbers in this table are based on the following configuration:
SQL Server 2000, installed on the same computer as SMS
A five-day work week
Three new advertised programs sent to all clients every week
All SMS site systems running Windows 2000 Server SP2 or later
Heartbeat Discovery run once per week
Hardware inventory run once per week (MIF generation)
Software inventory run once per week (.sic and .sid generation)
Status messages enabled (.svf generation)
Table 9.7 Number of Objects per Client per Week
Object type |
Number of objects per client per week produced with the specified configuration |
|---|---|
DDR |
1 |
MIF |
1 |
.sic or .sid |
1 |
.mux |
1 (Legacy Client only) |
.svf |
22 |
The values represented in Tables 9.5 and 9.6 are starting points. Use the values to facilitate the evaluation of your own site. Performance can vary considerably between organizations because of numerous variables, such as the number of clients, type of hardware, and available network bandwidth.
The data is also based on the assumption that the SMS Administrator console is run remotely most of the time, instead of being run directly on the site server. If you plan to use the SMS Administrator console heavily on the site servers, consider a faster CPU and more RAM for the site servers to improve the performance of the console.
Note:
- The total number of clients in a site is actually the number of clients that physically belong to that site plus the number of clients that belong to the site's lower level sites. In addition, if you enable discovery of users and groups, the total number of manageable objects can increase significantly.
Developing Initial Hardware Requirements
Using the performance metrics derived from monitoring the system, from the capacity models and values you generated, and from the system load signatures you identified, you can plan initial hardware requirements for the SMS site servers. Document these requirements in your SMS 2003 project plan. Ideally the hardware recommendation should meet the following requirements:
Zero processing backlog
Responsive help desk operations from remote consoles
Additional processing capacity to ensure timely recovery and minimal hardware cost
However, these numbers might require adjustments when you perform testing in your own lab environment and run the pilot project as described in Chapter 10, "Planning Your SMS Deployment and Configuration."
For small remote secondary sites that service the organization by managing only a small number of clients, you might need only very basically equipped computers. By using basically equipped computers in these cases, you can save a substantial amount of money.
For SMS 2003 sites that manage more than 100,000 clients - for example, a central site with no clients assigned to it - you should use quad-processor high-end computers with high-performance disk subsystems and plenty of memory. Because the performance variables become unpredictable at this size, it is especially critical that you run a pilot project to properly estimate the site server hardware.
Determining Site System Hardware Requirements
The CAP, distribution point, server locator point, management point, and reporting point roles require special consideration when you plan hardware requirements. This section describes these considerations.
Client access point
A CAP is primarily responsible for relaying the majority of the objects sent from Legacy Clients to the site server. It provides clients with the SMS 2003 client components during Legacy Client installation. The following items affect the load on a CAP:
The number of features that are enabled
Inventory collection
Software distribution
Software metering
Status messaging
The number of Legacy Clients in the site
The number of CAPs in the site
The number of total users in the site if you are targeting users for software distribution.
The CAP is also responsible for providing the files the client requires to perform software installations. The Legacy Client connects to this computer on a regular basis to check for new packages to install. In addition, the SMS Executive service and Inbox Manager Assistant run on this site system.
Note:
- All the CAPs in an SMS site contain all the files required for all the clients in the site regardless of which CAP a client actually uses.
You should also consider the data sent from clients to CAPs when you consider the appropriate hardware configuration for CAPs. This data includes discovery files, inventory, and status messages.
You should be aware that the load on a CAP increases at the following times:
During discovery
During SMS Legacy Client deployment
During software inventory (including file collection) on the Legacy Client
During hardware inventory on the Legacy Client
When a new advertisement is sent to the Legacy Client
When status information is sent up from the Legacy Client
When a large number of users log on to Legacy Client computers simultaneously
When you distribute greater amounts of software, you increase the amount of status that is propagated up the SMS hierarchy. The more inventory requirements you add to the SMS_def.mof file for hardware inventory, the larger the inventory becomes. The more files you collect with software inventory, the greater the amount of space required on the CAP. The shorter you configure the CCIM cycle, the higher the peak load on the CAP.
You can reduce the load on CAPs by:
Increasing the number of CAPs in the site
Lengthening the polling intervals for Legacy Client agents
Inventory collection
Software distribution
Software metering
Scheduling advertisements for nonpeak periods
Note:
- One of the issues to consider with large sites is that some Legacy Client software distribution files become very large as the number of clients increases. In some cases, each client within the site must read the same client lookup file on the CAP. By increasing the number of CAPs in the site, you decrease the load across all CAPs in the site. The more CAPs deployed within the site, the better the performance is for the client. However, the more CAPs in the site, the more replication of files between the CAPs and the site server. Consequently, the load increases on the site server. Testing in your isolated test lab is the only way to determine the optimum solution of this balance for your environment. Start by deploying a minimum number of CAPs within this test environment. Then gradually scale up the number of clients in the site until you've reached optimum performance for the configuration.
The main performance objects to track for sizing and capacity are those related to CPU utilization and queue lengths followed closely by disk and memory utilization. For more information about how Legacy Clients communicate with CAPs, see Figure 8.3 in Chapter 8, "Designing Your SMS Sites and Hierarchy."
Management point
You should size the management point server similarly to how you sized the CAP, because their roles are very similar. When you document the hardware requirements, remember that the management point also requires IIS. CAPs are simple file shares. Files are copied to them and forwarded to the SMS site server. Management points do additional processing of the files. CAPs use more disk space than management points, but management points use more processing time. Management points cache Advanced Client policy assignments for clients and as a result, memory is more of a concern than it is for CAPs.
The following items affect the load on a management point:
The number of features that are enabled
Inventory collection
Software distribution
Software metering
Status messaging
The number of Advanced Clients in the site
The number of proxy management points (placed in a secondary site) in the site.
The management point relies on the SMS site database for its client responses. One sizing consideration is the performance of SQL Server. If performance is slow, plan to implement an additional SQL Server for replication purposes.
You can reduce the load on management points by:
Lengthening the Advanced Client policy polling interval.
Scheduling advertisements for nonpeak periods.
Implementing an additional SQL Server to replicate the SMS site database.
Deploying multiple management points using Windows Network Load Balancing Service.
As with the CAP, the main performance objects to track for sizing and capacity are those related to CPU utilization and queue lengths followed closely by disk and memory utilization. For more information about how Advanced Clients communicate with management points, see Figure 8.3 in Chapter 8, "Designing Your SMS Sites and Hierarchy."
Note:
- Advanced Clients are managed by Advanced Client policy. This architecture is more scalable than CAP architecture. The replication issues mentioned for CAPs do not exist for management points. Each management point is able to support many more clients than a CAP can support. For sites consisting of a large number of Advanced Clients, the capacity planning strategy consists of deploying multiple management points using Windows Network Load Balancing Service and SQL Server database replication.
Distribution point
SMS 2003 clients access a distribution point to retrieve the package source files that are required to run advertised programs. Determine hardware configuration requirements for distribution points just as you would for any other file servers in the organization. For example, a large organization might have tens or hundreds of clients requesting 100 MB files from a distribution point. Software packages vary in size, so plan accordingly.
The following items affect the load on a distribution point:
The number of packages you distribute
The number of clients in the site
The number of distribution points in the site.
You can reduce the load on distribution points by:
Deploying one distribution point for each network segment within a site.
Deploying protected distribution points for network segments where bandwidth utilization causes a bottleneck.
Scheduling software distribution for nonpeak periods.
Scheduling advertisements for nonpeak periods.
Keeping target collections small.
You can control the load on distribution points by carefully scheduling software distribution. For example, if you are distributing Microsoft Office to the organization, you might want to spread out the load by creating several small advertisements targeted to different collections at measured intervals throughout the night. Alternatively, you can roll out Microsoft Office to every client at one time, but spread the load across multiple distribution points. Also, you can limit the load on the distribution point by limiting the number of simultaneous connections allowed.
Note:
- When you are distributing packages to child sites, you can also reduce the workload on the initiating site by using the fan-out feature. The fan-out feature allows sites to distribute package content to lower sites, through child sites rather than distributing the package directly. Fan-out distribution occurs automatically if the initiating site does not have an SMS address for the destination site. For more information, see Chapter 3, "Understanding SMS Features."
The main performance objects to track for sizing and capacity are those related to disk utilization, particularly read/write activity, and CPU utilization when read/write requests queue up quickly.
Server locator point
A server locator point is used primarily in client installation and is generally implemented in the SMS central site because the central site has information about the SMS hierarchy and the structure of the SMS sites in that hierarchy. It provides site assignment information and locates a CAP for Legacy Clients, or a management point for Advanced Clients, and directs the client there to complete installation. When you document the hardware requirements, remember that the server locator point also requires IIS.
The following item affects load on a server locator point:
- Client access for site assignment and installation
If you have enabled the logon script-based installation method, the Legacy Client accesses a server locator point at client logon time and produces minimal network traffic - approximately a 1 K upload and a 1 K download to the client. Similarly, the Advanced Client accesses the server locator point at client logon time for auto-assignment at its initial logon time, and generates the same amount of traffic as the Legacy Client.
However, server locator points do rely on accessing the SMS site database to obtain information about CAPs and management points, so it is necessary to monitor the network traffic generated between a server locator point and the site database server. For more information, see Chapter 8, "Designing Your SMS Sites and Hierarchy."
You can reduce load on server locator points by:
Creating a phased roll-out of SMS client software
Implementing an additional SQL Server to replicate the SMS site database
Reporting point
A reporting point provides read-only access to SMS reports using IIS. The reporting point can be installed on any computer running IIS, including the SMS site server.
The following items affect load on a reporting point:
The number of custom reports you create
The number of SMS users that require access to the reports
Because people require SMS information in many different forms, the requirements for SMS reports can vary widely. Depending on the amount of data and the complexity of the reports, SMS reporting can use considerable system hardware resources.
You can reduce load on reporting points by:
Deploying the reporting point on a server other than the SMS site server.
Scheduling large reports to run at nonpeak times.
Creating multiple reporting points for a site and assigning groups with similar reporting needs to a specific reporting point.
Note:
- Depending on the load that is generated during your lab test, you might consider deploying the reporting point on a dedicated server.
Determining SMS Site Database Server Requirements
SMS 2003 depends on SQL Server as its database engine. The database device configuration of SQL Server and the hardware resource needs of SMS 2003 are linked and have hardware interdependencies. It is recommended that the SMS site database be installed on the SMS site server. The performance of SMS 2003 is directly related to the performance of SQL Server. You must be sure to provide adequate hardware resources for both applications. To do so, you need a clear understanding of how these two applications work together.
Should SQL Server be installed remotely or locally?
SMS 2003 performs best when SQL Server is dedicated to SMS 2003 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 the server has been sized to accommodate both applications. Running SQL Server on the site server computer reduces network load. If you are using SQL Server for other applications within your organization, you must decide whether to use a remote installation of SQL Server for those applications. Running the SMS site database on the SMS site server is considered a best practice. Running SQL Server on a computer that is not the site server only benefits the site if you are using SQL Server for other applications within your organization.
Disk input/output is the most important factor in deciding where to locate the computer running SQL Server. Installing the data devices and log devices onto separate physical disks or RAID arrays improves the disk performance of SQL Server and indirectly benefits the performance of SMS.
How much data is written to the SMS site database on a daily, weekly, and monthly basis?
You can determine the amount of data written to the SMS site database by reviewing the number of clients that are reporting to the site and by reviewing the overall usage patterns, such as the flow of status messages, hardware and software inventory records, and DDRs, into the SMS site database. The total amount of data that SMS writes to the SMS site database can dramatically change the hardware that is required to optimize SQL Server performance. Often, if a large amount of data is written to the SMS site database only once per month, you require less processor power and disk space for SQL Server. Similarly, if a large amount of data is written to the SMS site database only during a particular part of the day, and you are not enabling many SMS features that require SQL Server processing, the server running SQL Server requires less processing power and disk space.
SQL Server uses memory for extensive caching. If it is given more memory, it uses it and runs more efficiently. Limiting SQL Server memory to a specific maximum amount reduces page faults and improves server performance. For more information about tuning the SQL Server memory cache, see the SQL Server documentation.
Another issue to consider when you are determining the hardware requirements for SQL Server and SMS component servers 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 the network before you run the pilot project, you can begin to estimate the amount of data that can accumulate and the size of the database required to store it.
To estimate the required SMS site database size for a single site, use the following formula as a baseline:
50 MB + (x × 220 KB) (where x is the number of clients in the site)
This formula is based on the following site settings:
Weekly hardware inventory, default SMS_def.mof
Weekly software inventory
Delete aged discovery records after 90 days
Delete aged inventory history after 90 days
Delete aged status messages after seven days
Weekly software metering summarization
The formula also allows for as many as 20 status messages per client, per week.
The algorithm used by SMS 2003 Setup allows 220 KB per client with a minimum SMS site database size of 50 MB.
Note:
- This value must be adjusted if these settings change. For example, if the default SMS_def.mof is modified to include additional inventory items being reported, the value might increase significantly.
After you have sized the database, then use the formulas and System Monitor counters suggested earlier in this chapter to generate a complete size and capacity plan for the site database server.
For More Information
Did you find this information useful? Please send your suggestions and comments about the documentation to smsdocs@microsoft.com.