Further Standard Image Definition


Obviously the best use of imaging and scripting (scripting is covered in Chapter 22) occurs after the server is completely configured. Chapters 12 and 13 will finish the building process by covering the Citrix installation and configuration, and the application's installation and configuration. Chapter 13 will also discuss software installation and version management automation using Citrix Installation Manager software. With all these things in place, the final cloning can be performed.

Server Sizing and Capacity Planning

With the maturation of server-based computing, a variety of software tools have emerged to provide SBC server capacity planning and testing. Mercury Interactive's LoadRunner (http://www.mercuryinteractive.com) and Scapa Technologies' StressTest (http://www.scapatech.com) have both developed an extensive set of planning, testing, and monitoring software tools that provide very sophisticated analysis and results for large enterprise environments attempting to determine how many servers will be required for a given user load and performance expectation. Both of these tools are relatively simple to use and will test the aggregate effects of all variables on a Terminal Server Farm, including server load, network bandwidth, encryption, compression, and so on. These tools make it very easy to run all-encompassing tests, and measure the results effectively.

But, with inexpensive, high-powered, small form-factor rack servers now readily available on every street corner, the tradeoff between an inexact estimate of the number of required servers and the time and money required to work with an enterprise tool must be weighed. Since neither tool is inexpensive (StressTest lists for $25,000 and LoadRunner lists for $50,000) it is our opinion that environments with less than 2500 users may benefit from a less expensive (albeit less automated) approach. We will detail an approach in this section that provides reasonably accurate server-sizing data points for small to mid-sized environments. Note that as an environment reaches 2500 users or more, this approach is very tedious and time-consuming, thus necessitating the use of one of the enterprise tools mentioned earlier.

User and Application Simulation

The goal of simulation is to determine with relative accuracy, the number of servers required to support a given amount of users at a given acceptable performance level.

Note

The number of terminal servers is not the only concern when considering the capacity and scalability of an environment. As an environment grows, other services such as network bandwidth, file servers, license servers, web servers, security servers, and others, will also require additional resources.

In order to build an effective simulation, it is important to define two variables:

  1. The major applications that the environment will support.

  2. The performance speed or response time required (typically defined in wait time) for a function to occur (for example, an acceptable wait time for Word to start after a user has clicked the icon might be 1.5 seconds, based on a typical wait time for users' current fat-client environment).

Once these variables are defined, there are three steps to complete the simulation and gather the data:

  1. Create a script or automated process to simulate a user running an application or performing a task.

  2. Prepare to monitor the server farm.

  3. Execute the scripts simulating multiple users, across multiple sessions (and preferably across multiple servers in a load-balanced test farm).

These three steps warrant additional discussion.

Create a Script or Automated Process Although the option of rounding up a large herd of test users and asking them to run their applications for several days in the test environment may sound appealing, in most cases it will be desirable to automate the process by creating a script or automated procedure to closely simulate the way users perform their jobs and tasks in the environment. The challenge with creating the script or process to run the simulation is that the users' use of applications and processes must be understood in order to obtain accurate results. This can only be accomplished by interviewing and observing live users prior to creating the script.

Once the approach is understood, the next step is to choose a scripting tool. Three potential scripting tools are WinTask, WinBatch, and AutoIT. These tools range in price from free to $100, and provide a macro-type recording feature, which creates a recording file that can be launched from a command prompt.

Preparing to Monitor the Server Farm Prior to actually executing the scripts, it is important to put a monitoring tool in place to gather results while the simulation is running. Two obvious monitoring and reporting tools are Citrix Resource Manager (RM) and Windows Performance Monitor. Since RM will be covered in Chapter 21, and Performance Monitor tends to be simple and quick to configure for this purpose, we will cover it briefly here:

  1. Configure Performance Monitor (perfmon.exe) to create a new log file.

  2. We recommend logging, at a minimum, the following counters on all servers in the test environment:

    • Terminal Services: Active Sessions

    • Physical Disk: % Disk Time

    • Memory: Pages/sec

    • Processor: % Processor Time:_Total

    • Network Interface: Bytes Total/sec

  3. Keep in mind that there are also specific counters for Citrix and Terminal Services (under Citrix and ICA and Terminal Services) that may be very helpful, especially for larger simulations where counters like Zone Collections, IMA traffic, and IMA data store communications need to be understood in order for background components and servers to be scaled appropriately.

Execute the Scripts Once the Performance Monitor logging is configured, we are ready to begin the simulation. Since connecting hundreds of client desktops and running from workstation to workstation to invoke the script is not on most folks' fun-to-do list, we recommend utilizing the Citrix Server Test Kit (CSTK) and a group of specialized client machines to automate the simulation of a large number of users and sessions. The CSTK is free, and can be downloaded from http://www.citrix.com/cdn.

A CSTK environment has four main components:

  • The CSTK Console This is the interface that runs on the server farm and is used to start and stop the tests, apply simulation scripts, and configure test-user accounts.

  • The user simulation scripts These are the scripts created in the previous section. The CSTK tool also includes some useful scripts for more generic tasks such as Internet Explorer and Microsoft Office 2000.

  • The CSTK client The client tool runs on every ICA test session and employs the user simulation scripts.

  • The client launcher utility This is the secret ingredient. It can be used to automatically launch multiple ICA clients from one PC or virtual machine environment. It also saves gobs of time over having to manually log on and launch 100 different sessions.

As we stated earlier in this chapter, we recommend simulating at least 10 percent of the final number of concurrent users. The CSTK supports running multiple test sessions from one client machine, although the number of sessions will be limited by the memory of the client machine (about 12MB of memory per client session is required). Thus, for small test environments, a group of thin clients or low-end PCs may provide sufficient capacity. In the case of a larger environment though—take our case study CME Corp., for example—a 10 percent test will require 250 concurrent client sessions. Clearly, a more creative approach will be necessary for larger environments in order to keep the test environment from becoming overly expensive and space consuming.

One approach that dramatically reduces the size of the client test environment is to utilize powerful client PC workstations running virtual machine software like VMware Workstation or Microsoft Connectix Virtual PC to create multiple client operating system environments that will each run multiple client sessions. Powerful PC workstations for this purpose can be procured for well under $1000 and can support up to 48 client sessions per workstation. The minimum specifications for the client test workstation are

  • Intel P4 1.6 GHz

  • 1GB of memory

  • 40GB hard drive

  • 100MBit network interface

  • VMware Workstation version 4 or Microsoft Connectix Virtual PC for Windows version 5

  • Windows 95, Windows 98, Windows ME, Linux, Windows 2000 Professional, or Windows XP—If the production environment will contain a mixture of these clients, then run a mixture on a test workstation. VMWare and Connectix both support hosting all of these running virtually as guest operating systems simulaneously from Windows Server 2003 or Linux.

Once the client test workstations are configured, load the CSTK environment and configure up to eight client sessions on each of six virtual machines within the server. Once the test is completed, turn off the performance monitor logging and go back to performance monitor to study the logs. Depending on the results, additional users can be added and tested, or fewer users tested to determine the maximum number of users supported at a specific performance expectation.

Brian S. Madden's well-written book Citrix MetaFrame XP Advanced Technical Design Guide, Second Edition gives the following step-by-step guide to using the CSTK (used by permission):

From this section, it is obvious that capacity planning is a multiphased, complex project, but it is an absolutely necessary project, in all but the smallest environments, to ensure success of a Terminal Services deployment.

start sidebar
Detailed Steps to Use CSTK to Conduct the User-Load Simulation

In order to understand how the CSTK works, let's review step-by-step how it's used:

  1. The first thing you need to do is prepare your environment. Ideally, you'll be able to run your tests on an isolated test network. Gather your MetaFrame server and the necessary ICA client devices. (You'll probably want to activate the Citrix licenses on your test server so that an annoying pop-up window does not break your scripts every ten minutes.) Just remember that "officially" Citrix advises against activating your server until it is finalized. It's your call.

  2. If you haven't done so already, install the CSTK on your server. (Remember to put your server into install mode first.) After the CSTK is installed, you'll notice that the "CSTK Client" is automatically launched whenever a user logs on. For now, you can just ignore that.

  3. Launch the CSTK administrative console. (Go to Start | Programs | Citrix Server Test Kit 2.1 | CSTK Console.) You will use this console to configure your testing environment and run your tests.

  4. Import the application simulation scripts created earlier into the CSTK environment. This process will make these scripts available to the CSTK. To do this, choose Tools | Add Application Scripts. You can specify anything you want for the Script Name. Use the "Browse" button to browse to the path of the executable of your script. You can specify any necessary command-line parameters in the Parameters box. For example, if you used AutoIt to create your script, you might need to specify AutoIt.exe in the Program Name box, and yoursrcriptname.txt in the Parameters box. Specify whether your application applies to "Normal Users" or "Power Users." Normal users will only run one script at a time, and power users will run multiple scripts simultaneously.

  5. After you've added the Application Test Scripts application scripts, you need to configure groups of test users that will use your scripts (go to User Group | Add, or click the plus (+) button on the toolbar). When you specify users, you're essentially indicating which application scripts run for which users when they log on. When adding a user group, the first question you're asked is whether you want to add a group of Normal Users or Power Users. Make your selection and click OK.

  6. Next, you need to specify a range of usernames that will run an application script (or scripts) when they log on. Specify the usernames by entering the basename and the number of users. For example, to apply a script to users "brian1" through "brian 5," you would enter "brian" as the basename and "5" as the number of users. If this is the first time that you're using the CSTK and you don't have any test user accounts created, you can click the Create Users button. This will create the test user accounts based on the baseline name and number of users. These user accounts are created with blank passwords.

  7. Before you click OK, highlight the script or scripts you want this user group to run and click the Add button. If you elected to create normal users, selecting multiple scripts will cause the users to run them one by one and the list of available scripts will only show those that you've designated for normal users. If you elected to create power users, selecting multiple scripts will cause the users to execute them all at the same time, and the list of available scripts will only show those that you've designated for power users. In a sense, normal users execute their application scripts in a "serial" fashion, and power users execute them in a "parallel" fashion.

  8. Once you add a group of users and click OK, you'll see them listed on the main CSTK console screen. You can add as many groups of users as you want (as long as the basenames are not the same in two different groups).

  9. At this point, the CSTK is fully configured and you should save your testing environment configuration. You can save the entire configuration, including user groups and applications, by choosing File | Save Configuration File. Your settings are then saved as an INI file with a .CST file extension. You can load your settings into the CSTK so that you don't have to manually set up everything from scratch in the future. When you save a configuration file, it does not include the application script information. When adding application scripts to the CSTK, they are available until deleted. If you delete one, loading a configuration file where it was used will not bring it back.

  10. In order to begin the testing process, choose Test | Start Test or click the lightning bolt button on the toolbar. You'll notice that starting the test doesn't actually do anything. You have to log users on in order for the scripts to execute. This is also a good time to start your performance monitor logging process as described back in step 6.

  11. From one of your ICA client devices, log on as one of your test users. This should be a user that is configured in one of the user groups in the CSTK console. Since a shortcut to the CSTK Client was added to the All Users\Startup folder when the CSTK was installed, it will launch after logon and the appropriate application script or scripts will start to run.

  12. In order to easily launch multiple ICA sessions from a single 32-bit Windows client device, you can use the CSTK Client Launcher. Log on to a client workstation and run CSTKlaun.exeCSTKlaun.exe from the "ClntLaun" folder of the CSTK directory. When you run it, it will detect the path of the ICA client executable (wfcrun.exe). Verify that this path is correct and enter the usernames that you want the sessions to be run from. The username entries follow the same baseline syntax as the groups within the CSTK. For example, if you have ten test workstations that you plan to use for ten sessions each, you would configure your CSTK for usernames "test1" through "test100." Then, you would configure the CSTK Client Launcher to use "test1" through "test10" on the first workstation, "test11" through "test20" on the second workstation, and so on.

  13. After you specify the users that will run on a workstation, you need to click the Create Entries button in the CSTK Client Launcher to create custom ICA connections for each user in the workstation's Program Neighborhood. Clicking this button brings up a screen that allows you to specify the default options used for each connection (such as the name of the server to connect to, protocols, and so on) Configure your options as needed and click OK.

  14. Before you run your test, click the Advanced Delay button to specify the delay between sessions. This allows you to choose how much time passes between launching sessions. One of the nice features is that it permits you to specify progressively more time as more sessions are launched, allowing you to anticipate slower responses as the server gets more loaded.

  15. After you've configured the delay, click the Run button on the Launcher's main screen. ICA user sessions will begin to be launched, and they will run the scripts that you specified for the user groups in the CSTK console.

As you add users to your testing environment, you should add them in small groups. For example, if you're testing 100 users, you might want to add ten users every five minutes for the first hour or so, and then add users one-by-one. By doing this, you'll be able to figure out how each user affects the overall system.

Don't forget to stop your performance monitor recording log once your testing is complete. Once it's stopped, you can examine it to determine the results of your test.

end sidebar




Citrix Metaframe Access Suite for Windows Server 2003(c) The Official Guide
Citrix Access Suite 4 for Windows Server 2003: The Official Guide, Third Edition
ISBN: 0072262893
EAN: 2147483647
Year: 2003
Pages: 158

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net