(Click here for printable version)

Article Detail:

1.      Moving the work from workstations to centrally controlled server based environment

This is becoming a common trend in the industry with more and more companies realizing that supporting critical applications on workstations distributed all around the office/country/world is not something they want to be doing for security, reliability and in many cases performance reasons. Workstations are hard to keep up to date, it's hard to police what versions are installed and used, they are often far away from data and may have a rather poor connection to the company network. When data is downloaded to local disks it becomes a security risk and changes can be easily lost without a backup.

2.      Running AXIS on a Terminal Server

More and more companies are setting up AXIS on terminal servers. In this configuration no AXIS components need to be installed and running on the workstation from which the end-user is accessing the application. The only piece of software that you need is a client program to the system that serves remote access from a workstation to the terminal server (e.g. Remote Desktop Client for Windows Terminal Services, Citrix client etc.). Everything (AXIS itself and the data)  resides and is running on the server side and all that the client computer does is to send keystrokes and mouse movements and receive the picture of the screen back. This setup requires much less network bandwidth between the client computer and the server than when AXIS is running locally on the workstation and is accessing data on the remote drive. Because of this, users can work from virtually any remote location via Internet / VPN etc.

Various modes to "publish" the applications to the clients exist in this setup, from showing just a window of one application (AXIS window only) to enabling access to the entire Windows desktop on the client side.

Now, this setup typically allows multiple users to work on the same physical terminal server in separate terminal sessions. While they do not normally see each other, or even know about each others presence, they share the resources of this computer such as processor power, memory and hard drives.

This is why we provide the following guidelines on how to configure terminal servers for AXIS so that remote users get proper performance when they use it concurrently. We recommend provisioning these servers with one physical processor core reserved for each concurrent user and at least 1 GB of RAM per core. The size and speed of the hard drives depends on the amount of data that you are planning to keep on the terminal server itself and whether there is a back-end GridLink farm or a SAN with larger drives dedicated for working and archival partitions.

Hardware Recommendations for AXIS Production Environments can be found at:

www.ggy.com/support/kbase/kbdetails.asp?articleid=677

www.ggy.com/support/reqequip.asp

3.      What if I have more concurrent users than processor cores in the Terminal Server?

Today you can set up a Terminal Server with up to 24 cores and this number increases from time to time.

If this is not enough, you should set up more than one AXIS Terminal Server with the total number of processor cores equal to the maximum expected number of concurrent AXIS users. You should assign each user to login to specific Terminal Server. Some systems (e.g. Citrix) offer automatic load balancing features so that the users are redirected to the server that is less loaded with work. At this point we do not recommend this method as it is important to have the user login to the machine that hosts his/her specific User Profile in AXIS (more on this below).

4.      What is installed on AXIS Terminal Server?

• AXIS Libraries (standard components required for AXIS to run: CodeBase, .NET Framework etc.)
• AXIS Versions (all required AXIS versions typically installed in uniformly named folders under one root folder)
• AXIS Software Security Key (since users login remotely, we provide special software keys for each licensed user so that USB keys do not need to be used)
• Terminal Services or Citrix software with appropriate licenses that controls user sessions.

5.      How do multiple users share AXIS installations on a Terminal Server?

AXIS stores system level parameters, user preferences as well as system level batch jobs in a special User Profile file. By default, there is only one user profile installed with the system. In order for multiple users to start AXIS from the same installation concurrently and to avoid overwriting each other's system level settings and objects, multiple User profiles must be created and maintained on the AXIS Terminal Server.

More details on this at:

www.ggy.com/htmlhelp/axis/42812.htm

6.      What can users do on AXIS Terminal Server?

Pretty much everything they would do with regards to working with AXIS on their workstations (other than distributed processing - see below)

• Run required version of AXIS
• Manipulate datasets
• Setup models (prepare assumptions, setup batch jobs etc.)
• Run batch jobs in non-distributed mode
• Review and process results (produce reports, run queries etc.)
• If other supporting application are published (e.g. MS Excel, MS Access) then the users can work with files produced by AXIS or prepare input data right on the terminal server
  

7.      Can users run AXIS batches with distributed processing on a Terminal Server?

If the AXIS Terminal Server is set up for multiple concurrent users then running batches with distributed processing will severely affect the performance for other users because all processing resources will be consumed by the multiple copies of AXIS. The impact may be reduced to some degree by limiting the number of helpers that each user can start but we recommend strongly against using this method because, in practice, it is very difficult to control and will not completely solve the problem.  Some batch runs may generate extreme loads on the disk drives even when only a few helpers are used.

If users run distributed processing jobs with automatic helpers on the Terminal Server, it is up to them to ensure that the number of Masters and Helpers running on that server does not exceed the number of processor cores, since each Master and Helper needs a core to itself. With multiple users running in independent sessions, it is almost impossible to control this, and very poor performance will result. It is far better to delegate the processor intensive task to GridLink which has the intelligence to maximize performance of any given hardware as described below.

8.      What is the optimal setup if distributed processing is required?

If you need to use distributed processing for AXIS models then the proper configuration is to set up a back-end processor farm under the control of AXIS GridLink. In this case the AXIS Terminal Server becomes a front-end server to the GridLink farm. The users submit jobs to GridLink from the copies of AXIS that they are running on the front-end server. AXIS GridLink processes jobs in sequence or in parallel, depending on the farm configuration, ensuring proper resources distribution. At the same time the users are free to perform other AXIS tasks on the front-end server (edit models, review results etc.) without being affected by heavy-duty number crunching.

More information on AXIS GridLink can be found at:

http://www.ggy.com/gridlink/overview.htm

Attached is a PowerPoint slide to illustrate the setup with a front-end AXIS Terminal Server and a back-end AXIS GridLink farm

9.      What is coming next?

We are pleased to announce that a new and very powerful module is currently under development. With its introduction we plan to transform server based environments similar to the one discussed above into truly Enterprise level data management systems for AXIS users. We have published a preview article on this module (AXIS EnterpriseLink) in a recent "Inside AXIS" newsletter which can be viewed at:

http://www.ggy.com/news/News200904/news200904.asp#topic2

• 1063-AXIS GridLink Setup with Front End Server.ppt

• Recommended Hardware for a GridLink Farm - May 2010