Published: November 12, 2007   |   Updated: February 25, 2008

The main role that requires scaling is the virtual application server role. It handles all communications with the SoftGrid clients. The VAS streaming infrastructure will need to meet peak demand when streaming a newly deployed application to the maximum number of possible clients. The following tasks provide guidance to determine the number of VASs that are required in a SoftGrid deployment.

Due to the relative recent availability of SoftGrid, most—if not all—deployments will be greenfield versus brownfield. A greenfield deployment is where a service is being introduced into an environment for the first time, whereas a brownfield deployment consists of an upgrade of an existing service.

Little research has been conducted as of yet to identify the core scaling metrics of a SoftGrid infrastructure. That is to say, there is no quantifiable data that can be presented to say that X servers should be deployed for Y users. Because of this, scaling and some capacity planning needs to be done once the environment is instantiated through creating a baseline of the system and looking at the growth trends.

Determining the resource requirements for each SoftGrid role is accomplished by using the performance monitoring tools in Windows Server to measure impact of the running system against key performance indicators. The Appendix contains information that will give the reader a basic understanding of performance monitoring in order to help plan both capacity and key indicators of performance bottlenecks. However, with today’s complex server systems, additional reading will likely be required to gain a strong understanding of server performance monitoring. Additional reference information is available at the end of this section.

SoftGrid Server Roles

The following table shows the basic performance and capacity monitoring that needs to occur to a given role within SoftGrid.

Table 4. SoftGrid Scaling Basics

* Given for completeness, these services are lightly utilized.

With the exception of Active Directory, the other four roles can be placed on a single server. This guide approaches scaling on a per role basis. The VAS does not have significant requirements around disk scaling other than to have enough space to store the OS and the SoftGrid VAS server application. The Content Storage System does have requirements around disk scaling. If these two roles are combined on a single server, then the requirements of both roles must be met by the single server.

It should be noted that while these four roles can be placed on a single server, scaling requirements and/or fault-tolerant requirements may preclude placing some combinations of roles on a single server.

Task 1: Active Directory

In addition to the general performance characteristics outlined above, additional performance counters are available to measure the performance and help in the capacity planning of Active Directory.

With this said, the SoftGrid infrastructure puts little load on the Active Directory environment. What load that is generated is simple LDAP queries to the directory. For example, the VAS will query Active Directory for the Security Identifiers for groups that are assigned to applications within the SoftGrid configuration database upon startup, and then cache in memory. Because these queries are light and infrequent, additional capacity and performance planning around Active Directory does not need to be done with the introduction of SoftGrid into the environment.

Active Directory performance should be monitored for performance degradation at all times. It may be necessary to upgrade domain controllers if performance drops below acceptable levels.

Task 2: Content Storage System

The content storage system stores the sequenced application packages. This content can exist on a file share that one or more VAS systems will access, or it can be stored locally on the VAS.

Shared storage can be a SAN based on Fibre Channel or Internet SCSI (Small Computer System Interface) (iSCSI).

If this role lives on the VAS directly, the CPU, memory, disk, and network need to be scaled to handle the number of peak concurrent application streaming sessions on the VAS. This is in addition to any additional requirements that the VAS needs. Since the storage is not shared among a number of VAS servers, a means for replicating the content should be investigated. For example, Distributed File System Replication (DFS-R) could be used to ensure that the various content storage systems are kept in sync.

If the content storage system is shared by a number of VAS systems, then the CPU, memory, disk performance, and network need to be scaled to handle the peak concurrent streaming sessions on all of the VAS systems that are using this shared content.

What is important is that the throughput from the storage device to the VASs is consistent. If degradation occurs, application performance from the VAS will be adversely affected.

Task 3: Management Web Service

The minimum server requirements for the SoftGrid Management Web Service are listed in the following table:

Table 5. Minimum Server Requirements for Management Web Service

The Management Web Service is used by the Management Console to control the SoftGrid system as well as to run reports. With the exception of running reports, other requests of the Web service are extremely lightweight. If reporting is not being used, then the Management Web Service can be placed on a VAS.

The Web service should be placed on its own server if administrators plan on running the built-in reporting capabilities since this places a large CPU load on the server.

Task 4: SQL Server

For each SoftGrid system, a SQL Server database is required. This SoftGrid database can be located on a dedicated SQL Server instance or it may be located on a SQL Server instance that has sufficient capacity to accommodate the SoftGrid database along with any other databases that reside on that instance.

The minimum server requirements for the SQL Server-based computer hosting the SoftGrid database are listed in the following table.

Table 6. Minimum Server Requirements for SoftGrid Datastore

In addition to the general performance characteristics outlined above, additional performance counters are available to measure the performance and help in the capacity planning of SQL Server. However, the load generated by SoftGrid against SQL Server for configuration information and application activity and usage monitoring should not significantly increase the load on an existing computer running SQL Server. SQL Server performance monitoring should be performed as an operational task to ensure that the server adequately responds to requests from SoftGrid.

The database growth can be calculated so that proper capacity planning for the disk capacity can be accommodated.

The SoftGrid configuration database is initially only 2 MB and will usually not grow past 10 MB in most system configurations. The application data is the only configuration data that noticeably changes the footprint for configuration data. It would take a very large number of applications to exceed 10 MB of configuration data.

The SoftGrid metering data is the information about application activity and usage. The row size for the metering tables can be up to 5 KB; however, events such as starting and stopping applications take only about 1 KB. In an environment having approximately 2,000 users who start and stop about five applications each day, the metering database would grow about 20 MB* per day ( 5 Applications * 2 1K Events open and close application * 2,000 Users).

By default, a database cleanup routine is set to run; it deletes the “old” rows. The two settings for controlling what data is “old” and gets deleted are Database Size and Usage History. These settings are found in the System Options dialog of the Server Management Console.

The Database Size setting (default = 1024 MB) allows the database data files to grow up to that size. There is a database alert that monitors the data file size and upon reaching this limit, it will start the procedure that cleans up the data. This process uses watermark settings to keep the data trimmed back to a certain percentage of total capacity. It calculates an approximate date and deletes all metering data older than that date.

The Usage History setting (default = 6 months) keeps the metering data for the specified number of months. At the beginning of every month, the database job runs to clean up the data. All sessions that completed prior to the cutoff date are deleted.

The tables MESSAGE_LOG and APPLICATION_USAGE are affected by these cleanup jobs.

Task 5: Virtual Application Server Scaling

The scaling of the VAS is highly dependent upon the environment in which it is placed. There is no hard guidance available for determining the amount of memory, processor, or networking requirements for a “typical” scenario as they are all different.

The minimum server requirements for the SoftGrid Virtual Application Server are listed in the following table.

Table 7. Minimum Server Requirements for VAS

Some key points that might affect the server or environment should be considered: The streaming protocol used by the VAS does not provide a means for limiting the amount of network bandwidth the system will attempt to use. In highly starved networks with low available bandwidth, the ability to successfully stream an application can be greatly hindered.

The pattern of access to the applications can affect the server. Large numbers of users launching an application at a specific time can saturate the network and stress the VASs. If applications are frequently updated or if a large number of updates have been made, then large amounts of data can be put onto the network.

The method of deploying the application in the environment can have an impact. For example, are applications fully cached on the client? This results in only pulling updates when the application is patched. However, it also requires a large download of the application initially. If an application is streamed on demand, then a smaller amount of data is initially streamed. But depending upon usage, additional blocks will be streamed and cached when new features are invoked that were not part of Feature Block 1.

Frequent logons can generate load against the infrastructure if desktop configuration refresh is configured to occur at user logon. A desktop configuration refresh is the process the SoftGrid client initiates to identify the applications to which the user has access. The desktop configuration server used for desktop configuration refresh and the database with which the server communicates can have increased loads if significant desktop configuration refresh requests are processed in a short period of time.

In addition to network performance impacts due to the amount and frequency of the streamed data, the act of streaming also has a processor impact on the server. A sufficiently large number of streams can cause the server to become processor-bound, regardless of the available network bandwidth.

Additionally, depending upon the protocols chosen, additional processor overhead can be incurred with streaming. If a protocol that supports encryption is used, then additional processor overhead is required to encrypt the stream.

This is just a sampling of the variables that can affect the performance and scaling of the VAS. Because a number of these variables are related to the environment, testing within the environment where the SoftGrid services will run is required. Once a baseline is established on the size of the servers, additional servers can be added for redundancy and/or to increase capacity. Start with one VAS server (or two if required for fault tolerance) and add additional servers as required. Performance monitoring should be done on the VASs to help plan for additional capacity and performance requirements.

Decision Summary

There is no hard guidance around server capacity planning for SoftGrid 4.2. This step helps in identifying the key requirements for scaling the individual components within the SoftGrid system. This should be repeated for each SoftGrid instance.