Lesson 3: The Resource Planning Phase in Detail
Resource planning and testing a site design in the lab should occur concurrently. At the end of the resource planning phase, the question of the design's impact on existing hardware and network bandwidth is revisited. The administrative requirements associated with deploying SMS and managing the system are resolved at this stage.
After this lesson, you will be able to
- Select hardware resources that can accommodate the software used in an SMS site design.
- Assign administrative resources to the management of the entire SMS hierarchy.
Resources to support the design fall into two categories: hardware (selecting computer and network resources) and staffing components, as shown in Figure 9-4.
Figure 9-4. The components of resource planning.
Planning Server Resource Requirements
SMS contains various services that can be distributed or that act upon a number of computers in the network. One computer can house all of the services, thus performing many of the SMS functions. In a small network, acceptable performance levels can be achieved with a single SMS primary site server configuration. However, in medium to large networks, several site systems should be used to support the various SMS functions. The following site system roles are configured on multiple computers to distribute SMS processing:
- Site database server
- Primary site server
- Secondary site server
- Component server
- Logon point
- Distribution point
- CAP
- Software metering server
- Software metering database server
NOTE
Some functions in the preceding bulleted list are mutually exclusive. For example, a primary site server cannot be a secondary site server and a secondary site server does not use a local SQL Server database for SMS data storage.
Chapter 2 of this book and Appendix A of the SMS Administrator's Guide discuss minimum requirements for running SMS. Reviewing minimum requirements is a good starting point for site system capacity planning. However, the key to site system sizing is determining the load signature on each computer providing SMS functions to the site. A load signature identifies how hardware is being utilized. Armed with this information, you determine how to improve performance of SMS functions.
The following sections of this lesson investigate details about the behavior of the most critical site systems. Using these details, site database and site server information in Chapter 2 of this book, and the minimum requirements as outlined in the SMS Administrator's Guide, a load signature and an acceptable level of performance is determined.
Site Database Server
SMS services in a primary site make extensive use of SQL Server to maintain and update the site database. Thus, SQL Server performance is critical to smooth site operations. SMS performance with respect to SQL Server depends upon the following factors:
- SQL Server (site database server) hardware capacity and performance
- Fast network access between the site database server and the site server
- SQL Server configuration settings
- Location of the SMS Provider
Determining what computer will run the SQL Server software should be based on available hardware resources, the size of the SMS implementation, the speed of the network, and database processing requirements. The site database server is either located on the primary site server running SQL Server or on a SQL Server other than the primary site server. In addition, one SQL Server can support multiple site databases in a multi-site hierarchy.
SQL Server must be configured specifically for SMS. The required tuning procedures may conflict with existing databases. Thus it is recommended that a SQL Server computer be configured to support only SMS databases. For more information about tuning SQL Server for SMS, see Chapter 2, Lesson 1, "SQL Server Support and SMS."
NOTE
This recommendation is consistent with the real-world implementations of Microsoft BackOffice applications. Most large companies are investigating larger server platforms to allow for the consolidation of services onto fewer hardware platforms to ease the support burdens.
SQL Server on the Site Server
Installing SQL Server on the site server computer allows for bus speed communications between the SMS services and SQL Server. A computer with hardware capable of delivering high performance for both the site server and SQL Server should be used to take advantage of bus speed communication. If a network runs a high-speed backbone, then high-performance communications between a site server and a site database server are possible.
NOTE
Before determining where SQL Server should be placed, review licensing issues under the section titled "Licensing Systems Management Server" in Chapter 1, Lesson 2, "Environment & Terminology."
SQL Server on a Separate Computer
An alternative to using a single server for both site server and site database roles is to improve network bandwidth between the site server and a separate computer running the site database. Under the following conditions there are good reasons to separate the site database from the site server:
- For administrative or financial reasons a computer powerful enough and dedicated to running both the site server and the site database is not available.
- The site is primarily functioning as a software distribution facility and inventory collection is infrequent.
- The network connection between the site server and the computer running the site database is fast and reliable.
- SQL Server runs other databases including SMS databases.
- SQL Server performs other non-database-related processing.
Software distribution requires a great deal of computing resources on the site server for compression and, for site servers also acting as distribution points, decompression of files. For example, disk capacity package requirements can be four times the size of the software being installed.
Running Multiple SMS Databases on One Server
It is possible to install multiple SMS databases on one SQL Server. This is necessary under the following conditions:
- Housing both the site database and the software metering database on a single computer.
- Keeping an SMS site running when a local SQL Server fails.
- Ensuring fast, reliable access from a SQL Server to primary sites that do not process a large amount of inventory.
- Spreading database requirements to underutilized SQL Servers.
- Allowing for centralized management of all SMS/SQL Server databases.
If only one copy of SQL Server is available and software metering is required, install the site database and software metering database on a single computer.
If a site's SQL Server fails, the site's database can be moved to another primary site's SQL Server. When the SQL Server is repaired, the other site's database can be moved back to its original location.
This saves on hardware expenditures, but it is not recommended for busy sites.
During management functions, a large amount of data can be passed between computers running the SMS Administrator console and the SQL Server database. In addition, there may be many SMS Administrator console sessions operating on each SMS database simultaneously. This should be considered before placing multiple SMS databases on a single SQL Server.
Whichever SQL Server configuration is chosen, it is easy to move the SMS database as long as it is on the same hardware platform (x86 or Alpha) as the original installation. See Chapter 13, "Administering SMS Databases," for details.
SQL Server Hardware Recommendations
Sizing the SQL Server computer to accommodate the load SMS places on the SQL Server processes is critical to the smooth operation of SMS. While network bandwidth, processor, and bus speeds influence the operation of SQL Server, RAM and hard disk I/O performance and capacity are the most critical factors with respect to SMS.
RAM
One of the easiest ways to increase SMS performance is to add random access memory (RAM) to the SQL Server computer.
After RAM is added to the SQL Server computer, it must be allocated to SQL Server. (See Chapter 2, Lesson 1, "SQL Server Support and SMS.") The amount of memory specified must be sufficient for the SQL Server static memory needs (kernel overhead, user stack space, and so on), as well as for the procedure cache and the data cache (also called the buffer cache). If this additional RAM is not configured for use by SQL Server, other processes on the computer running SQL Server will make use of the memory.
NOTE
Details on hardware requirements and database sizing are given in Chapter 2.
Monitoring Available Space
Since database disk space is initially pre-allocated, it is important to monitor the free space left in the data and log devices. If space is getting low, expand the device that is nearing its data capacity. In SQL Server 7.0 you can configure the database so that it automatically expands as needed.
To find the amount of space used in the database devices, run the sp_spaceused SQL stored procedure against the SMS and tempdb databases. This SQL stored procedure is run from the ISQL/w query tab. Figure 9-5 shows the results of running sp_spaceused against an SMS database named SMS.
Figure 9-5. SQL Server 6.5 ISQL/w showing the results of the sp_spaceused transact SQL command.
Divide the reserved value by the size of the database_size value.
For the site database, if this value is over 80 percent, expand the database. For the tempdb data device, if this value is over 60 percent, expand the database.
NOTE
Tempdb grows as it is used. Thus, the space used in tempdb should be checked when database access is at its peak, for example, when several copies of the SMS Administrator console are querying the database simultaneously. The SMS Administrator console utilizes tempdb as does site server processes. Even a few running instances of the SMS Administrator console could consume all of the space allocated to tempdb.
Primary Site Servers
Every network environment is different and typically changes over time. This fluid nature of networks means that resource requirements alter as the network evolves. Use the information provided in the following section to make an educated estimate of current resource requirements. Also make sure that the resources committed to the SMS design can grow to meet future requirements.
Primary Site Server Hardware Requirements
To review minimum hardware requirements, read Chapter 2 of this book and Appendix A of the SMS Administrator's Guide.
CPU
In small to medium SMS sites, the CPU is rarely the performance bottleneck. Often the minimum required CPU provides adequate system performance on the site server. In large SMS sites, the CPU can become a bottleneck, especially if the site supports many subsites and site systems. Regardless of site size, if the site server is running SQL Server, additional processing power will be required. As previously discussed, the SQL Server can move to another computer not running the core SMS services.
Use the Performance Monitor in Windows NT/2000 Server to observe processor utilization. System-%Total Processor Time should average below 80 percent. Occasional peaks above 80 percent do not justify processor upgrades. The System object—rather than the Processor object—is tracked in order to watch processor utilization on all processors in a multiprocessor computer using the multithreaded SMS services. In a single processor computer, the System-%Total Processor combination yields the same information as the Processor_%Processor Time value. To determine the load created by each SMS service, track the Process-%Processor Time for each SMS process and Thread-%Processor Time for each thread of the SMS Executive service. Track the System-Processor Queue Length to verify that threads are not backing up while they wait for processing. Processor Queue Length should not be greater than two on average. You must track a thread counter such as Context switches/sec to obtain any information from the Processor Queue Length counter.
Memory
RAM requirements for a site server are less significant than RAM requirements for a SQL Server running the SMS databases. To determine the appropriate amount of RAM for a site server, track the following counters in Performance Monitor: the Committed Bytes counter and the Memory-Page Reads/sec counter. If Committed Bytes are consistently lower than the amount of physical RAM in the site server, then no additional RAM is required. If Committed Bytes are consistently higher than the amount of physical RAM and there is excessive disk activity, then RAM should be added to the site server. The Memory-Page Reads/sec counter should be below 5. More than 5 Page Reads/sec indicates that the Virtual Memory Manager is reading too much data from the page files rather than pages in RAM.
These RAM requirements are for services involved with the functions of the SMS site server. Other application processes require additional RAM. To reduce the RAM requirements of the site server, move some SMS services to other site systems.
NOTE
The SMS Administrator console utilizes a significant amount of memory on a site server if run locally. Therefore, when possible, run the SMS Administrator console on another computer in the network rather than on the site server.
Disk
If Windows NT/2000 Server, SQL Server, and SMS are installed on the same disk, performance will suffer unless the logical disk appearing in Windows NT/2000 Server is actually a RAID (Redundant Array of Independent Disks) implementation. It is preferable that the disk array is implemented in hardware by means of a disk array. Alternatively, Windows NT/2000 Server's software can be used to create a disk array. Windows NT/2000 Server disk array implementations, however, will not provide the same performance levels as a hardware-level RAID configuration.
An array of disks with a cached SCSI bus-mastered controller dramatically increases the performance of SMS. For a multiple logical disk implementation of RAID, separate the major disk users by loading them onto different disks. Install Windows NT, SQL Server log and data devices, and SMS on separate logical disks. To further optimize disk performance, use multiple disk controllers, faster disk drives, or a faster system bus.
NOTE
Many hardware manufacturers create specialized versions of their server platforms to meet the requirements just outlined. It is helpful to investigate the different platforms available to ensure the best performance for your software configuration.
Use the Performance Monitor in Windows NT/2000 Server to observe disk throughput. Physical Disk-%Disk Time should average below 80 percent.
NOTE
Make sure diskperf -y is run from the Windows NT command line to enable disk monitoring. In Windows 2000, disk performance counters are enabled through Device Manager.
SMS functions utilize hard disk space in varying amounts on the site server. The SMS functions to be used in the site design were determined early in the planning phase, during the needs analysis. As a general rule, make sure that a site server running all SMS functions is allocated at least 1GB of disk space.
Packages typically occupy the most space on the system. Determining package disk space utilization requires additional calculations that are not necessary for other SMS components. The general rule is to allow four times the amount of disk space for package files as are used by the application source files. At a minimum, the package files will take two times the space required for the original source files. The following table uses data from a typical installation of Microsoft Office 97 to demonstrate space requirements if the site server is also used as a distribution point.
| Description | Disk space required |
|---|---|
| Application Source files installed through an administrative setup of Microsoft Office 97. | 273 MB |
| If the compressed package is stored on the site server, it will use ~ 1/2 the space of the source files. | 136 MB |
| Compressed package received on the site server. | 136 MB* |
| Master copy of compressed package stored on the site server. | 136 MB |
| Compressed package decompressed on the (tempdir) site server. | 273 MB** |
| Decompressed package copied to the distribution point, which will be the site server if the site server is used as a distribution point. | 273 MB |
| Total space used. | 1227 MB*** |
* The compressed package is moved from the RECEIVE directory to the STORE directory and decompressed to the TEMP directory.
** The temporary directory files are automatically deleted after the package has been completely decompressed and sent to the distribution point.
***During package processing, peak utilization on the server will not reach 1.227 GBs, since the package is removed from directories during distribution. Further, most distribution procedures occur across multiple servers. Therefore, use the calculations above to determine the maximum utilization of disk resources.
TIP
The previous reference assumes that the process completes without error. It is prudent to plan for the worst possible scenario, particularly when it comes to available disk space. Thus, it is better to have too much than too little disk capacity.
Secondary Site Servers
Since secondary site servers do not manage a SQL Server database and cannot have subsites, they require fewer resources than do primary site servers. RAM and disk space requirements are the major concern on secondary site servers. Network bandwidth issues associated with site-to-site communications are discussed in Lesson 2 of this chapter and in Chapter 11.
Disk
System files use approximately 40 MB of disk space on a secondary site server.
If software distribution is used at a remote site but the secondary site server is not used as the distribution point, packages are received at the site server and copied to the distribution point. Disk capacity is still required on the secondary site server for packages, since they are stored on the server's disk.
RAM
64 MB of RAM is recommended for a secondary site server. Even in larger sites, the RAM requirements do not increase significantly because the secondary site server simply passes data to and from a primary site server (parent) in the hierarchy.
Component Servers
Component servers are designed to offload processor utilization from site servers by moving threads of the SMS Executive service to other Windows NT/2000 computers on the network. Some thread functions provided by the SMS Executive, such as sender threads, can be moved to multiple component servers.
Component servers are most commonly used for running additional senders. For example, the site server runs the Standard Sender while one component server runs the SNA RAS Sender and another component server runs the ISDN RAS Sender. So with component servers there are three methods for sending data to other sites in the hierarchy.
RAM
Since a component server runs threads of the SMS EXECUTIVE service, RAM requirements are minimal: 2 MB of RAM for a sender is adequate. Since component servers must be Windows NT/2000 Servers, make sure there is adequate memory to run the operating system as well.
Disk
If a component server is used for sending packages from one site to another, make sure there is enough disk capacity to accommodate compressed packages. After the package is sent, the disk space used will be returned to the component server.
Domain Management and Site Systems
SMS can be installed on any Windows NT/2000 computer in a Windows NT/2000 domain. The site server need not be a domain controller, but it must be registered in a domain. There are several compelling reasons to place the SMS site server on a member server rather than on a domain controller or in a distinct SMS domain. Using a member server for the site server removes the processing overhead of domain management from the site server. By creating a distinct domain for SMS, reconfiguring the site server or client computers managed by the site server will have a minimal impact on the users. Within a distinct domain, SMS troubleshooting is isolated from network logon troubleshooting, since the site server's domain is not acting as a logon domain.
SQL Server can be set up in its own domain so that SQL administrators have full control of the SQL Server computers. The SQL Server may also be configured as a member server in a domain so that it doesn't have to participate in domain management functions.
Windows NT/2000 logon points are the only site systems that must be domain controllers. All other site systems should be configured as member servers to segregate domain management from site system functions.
Separating site systems in this way is more important in larger SMS implementations. However, smaller organizations with adequate hardware resources to support this model should consider it, particularly when site growth is likely.
Resource Planning and Other Site Systems
The same Performance Monitor counters used to determine the load signature on the site server should be run on all the site systems discussed in the following sections. This monitoring provides an objective measurement of load signature. Using this data and the following information about site system functions, you can better allocate resources to meet performance goals.
Client Access Points (CAPs)
CAPs are created when installation methods are enabled. This site system is the primary communication point between client computers and the SMS site. Client computers frequently poll CAPs for client agent updates and advertisements. Discovery and inventory data is passed from the client computers in the site to the CAPs. Including CAPs in a site design where they are not required only places a heavier load on the site server. Any CAPs that are not required should be removed from the network.
Conversely, if existing CAPs are too heavily loaded with client computers to manage, add more CAPs or increase the capacity of the existing CAPs.
Logon Points
Logon points are created when domains are selected for Windows Networking Logon Discovery and/or Windows Networking Client Installation. All domain controllers within the selected domain become logon points. Logon points are also created when NetWare NDS and Bindery Logon Discovery and/or Installation Methods are enabled and NetWare site systems are targeted as logon points.
Much of the processing previously required for logon servers in SMS 1.2 has been removed from the logon point in SMS 2.0 by distributing logon server functions into two site systems; the logon point and the CAP. The logon point provides initial discovery of computer resources and installs SMS client computer programs. The CAP acts as the primary communication point between the client computer and the site. SMS functions running on the CAP require more computer resources than SMS functions running on logon points. Therefore, if the CAP and logon points will be configured on separate site systems, consider allocating more computer resources to the CAP than the logon point.
Distribution Points
Distribution points require reliable and fast connections to client computers for installing and sharing applications. These servers require significant disk capacity to be able to receive packages.
Fast and Reliable Access
Each client computer receiving packages needs access to at least one distribution point. As mentioned, the site server can act as a distribution point. In medium to large SMS implementations, this is not recommended.
If there are client computers running Novell NetWare redirectors in a site, then a NetWare server must be available as a distribution point.
Significant Disk Space
This requirement is dependent on the size of the packages that will be distributed. After decompression on the site server, the application source files in the package are delivered to distribution points. These files remain on the distribution points until all advertisements using this package are removed. See the section in this lesson titled "Primary Site Server Hardware Requirements" to review an example of disk space requirements for the Microsoft Office 97 package.
Running the SMS Administrator Console
Because the SMS Administrator console is an interface to the site database on the SQL Server, there is much network traffic generated between the interface and SQL Server. The SMS Administrator console benefits from a fast client computer processor, sufficient RAM, and fast network access to the SQL Server.
NOTE
When not using the SMS Administrator console, close the application. As long as the SMS Administrator console is running, it will consume up to five SQL Server connections, which is a waste of valuable RAM in the SQL Server computer.
The SMS Administrator console can be installed on any computer running Windows NT Server/Workstation version 4.0 or Windows 2000 Server/Professional. Because the site server is already heavily loaded with SMS services, avoid using the site server to run the SMS Administrator console.
SMS Client Computers
SMS uses a limited amount of resources on client computers. Performance is most significant when the SMS client computer software is first installed. Whenever client computer options are changed at the site server, processing on the client computer to implement the changes will impact client performance as well.
Windows 32-bit client agent processing occurs in the background when the computer is not busy with other tasks. Client agents running on Windows 16-bit client computers impact computer performance more noticeably than those running on Windows 32-bit client computers.
Network Bandwidth Planning
Within a Site
Network bandwidth within an SMS site can become a performance bottleneck. In Ethernet environments, network utilization should remain below 40 percent on average. In unswitched Ethernet networks, as network utilization increases, so do collisions.
Using Network Monitor or other network management tools, determine network utilization on each segment in the network. If it is consistently over-utilized, consider adding virtual LANs, adding switches, physically segmenting the network using routers, relocating servers, or upgrading other network components to increase network bandwidth.
NOTE
See Chapter 7 for a detailed discussion of Network Monitor.
Between Sites
Bandwidth requirements are significant when secondary sites are installed and connections between primary sites are created.
Secondary Site Creation
Network traffic as a result of a secondary site installation can be reduced by initiating the secondary site installation from the secondary site location, or by initiating the installation from the primary site but specifying the secondary site as the location of the installation files. Network traffic between established sites in the hierarchy can also be significant depending on the bandwidth of the connection between the sites and the SMS functions supported on the child site.
Attaching a Primary Site to a Parent Site
If a new primary site is attached to its parent site before collecting inventory at the child site, there is no significant network load. If the child site has collected inventory, then the site database is compressed and sent as a single file. This single file can be quite large if the child site has collected inventory on many client computers. Therefore, it is best to connect to the parent site before inventory is collected. If inventory has already been collected at the child site, establish the connection between the parent and child during periods of reduced network activity.
Sending Client Computer Inventory to Parent Sites
Inventory data is passed to a parent site only if inventory information has changed (a delta-MIF file), if there is a resynchronization, or as required to maintain updated inventory data. Network load caused by the passage of delta-MIF files between established sites is approximately 5 percent of the total size of inventory data at the child site. Inventory data is passed from a child site to the parent site through the hierarchy until it reaches the central site. For example, if a full inventory or resynchronization data file is 40 to 80 KB in size, a partial inventory will be approximately 5 KB in size. Because Windows 32-bit client computers process inventory locally, inventory data sent over the network to site servers is significantly reduced.
Files of any size can be collected by the Software Inventory Client Agent. Since these files are passed to the parent site, caution should be exercised before initiating file collection. Collecting large files from many client computers in an SMS site significantly compromises network utilization. To reduce the effect of file collection, limit the size of collected files through the properties of the Software Inventory Client Agent.
Sending Status Information from Child Sites to Parent Sites
Most status information files are small and do not significantly contribute to network utilization. However, recurring errors or a large number of errors increases network traffic significantly. To reduce the impact on network utilization caused by status information files, be sure to remedy the error, or errors, causing the creation of these files. Further, configure the child sites so that status messages are not replicated to the parent site but do allow the status summaries to be replicated to the parent site. This provides a summary view of information about the child site at the parent site. If a problem is detected, connect to the child site to view the actual status messages.
Intersite License Balancing
If software metering occurs between sites, the software metering servers will generate network traffic between sites. If the sites are connected via a low-bandwidth connection, carefully evaluate the number of applications that are being metered and whether online software metering is really necessary. Offline license metering eliminates intersite license balancing. Intersite license balancing only occurs down the site hierarchy from parent to child.
Software metering configuration data, such as new product licenses and additions to the Excluded Programs list, flows down the site hierarchy. Usage data, callback requests, and other information passes up the site hierarchy. To reduce the network traffic associated with license metering activity, configure increased time intervals between license metering.
Sending Packages to Child Sites
Packages are sent in compressed form from the originating site directly to any destination sites. That is, if a package is destined for a child site and its child site, two copies of the package are sent from the originating site. Large packages have a significant impact on network utilization. Therefore, make sure to send packages to child sites during periods of reduced network activity or use the Courier Sender to send packages. See Chapter 11 for information on controlling network utilization between sites.
Other SMS Communications that Generate Network Traffic
Site-to-site communication generates network traffic to maintain the site databases and to send reconfiguration data from parent to child. The following activities should be monitored:
- Collection evaluation
- Discovery data
- Site configuration changes
- Remote Tools sessions
Collections are evaluated for membership and updated at parent and child sites in the hierarchy. To reduce network traffic resulting from collection updates, for each dynamic collection, reduce the update schedule and remove any unnecessary collections. Collection rules are not passed from primary sites to secondary sites.
Discovered resources are passed between sites as DDRs. Network devices and computer resources added to the network generate discovery data depending on the discovery methods and installation methods enabled on the site. Do not enable unnecessary discovery or installation methods.
Site boundary changes and sites attaching together generate network traffic. However, this traffic is incidental unless a child site has collected a significant amount of inventory. See the previous section, "Attaching a Primary Site to a Parent Site," for more information.
When an administrator connects to another site to perform Remote Tools functions, network utilization between the sites increases. Remote sessions should be terminated when they are completed. If Remote Tools are used extensively and network utilization is a problem, consider configuring additional senders to increase available bandwidth between sites.
Administrative Personnel
Once hardware resource requirements to support the site's design are determined, you must choose staff to support the system. A lack of properly trained staff will cause any carefully planned and deployed SMS implementation to fail. During the education phase of the plan, many IS staff members receive training on the system. Their training is augmented during the testing phase. Aptitude for SMS management and individuals' particular areas of interest with respect to the network should be considered before selecting personnel to manage the system.
Since networks are dynamic in nature, staffing requirements are likely to change even during the initial deployment of SMS. While a small SMS implementation can be handled by one person, large SMS implementations will require the support of several staff members. Large organizations should form a centralized team of at least two to three SMS administrators to manage the system.
The following roles are common in large SMS implementations:
- Technical architect
- Project manager
- Site administrator
- Site operator
- SQL Server administrator
- Site communications manager
- Job (or application installation) automation developer
- Support staff
See the table under "Personnel and Time Requirements" in the SMS Administrator's Guide for detailed explanations of the roles, responsibilities, technical knowledge, and variables involved in assigning administrative resources.
These roles may be filled by one person or by several people, depending on the size of the SMS implementation. It is important in designing a good plan to consider each job description and determine how roles should be filled.
EAN: 2147483647
Pages: 107