 |
|
|||||||||||||||||||||||||||||||||
AXIS GridLink Controller and Utility
AXIS GridLink Controller and GridLink Module Utility are 2 components of the AXIS GridLink Module.
Please note that it requires the AXIS GridLink Module Licence.
Please note that AXIS GridLink Controller can only run on Windows 2000 Professional, XP Professional, 2000 Server, and 2003 Server.
AXIS GridLink Service
A GridLink controller running on a machine with a valid licence is called a licenced controller, which serves as an entry point to the farm from a client machine outside of the server farm. A licenced controller can receive batch jobs submitted by AXIS users, launch AXIS master and helpers to run jobs, and allow users to monitor the job status. A licenced controller can request other controllers, including non-licenced controllers, to launch helpers to help the master in a distributed batch job. The controller keeps a queue of batch jobs submitted from users. The jobs run on the server farm in sequence. Users can connect to the controller to monitor the job status and control the jobs.
GridLink controller runs as a Window service. Whenever the server is rebooted, the service will be restarted automatically without any interactive user log on session.
GridLink Service can be installed, uninstalled and managed from a remote central location by using GridLink Utility.
AXIS GridLink Utility
AXIS GridLink Utility runs on the user's local machine and allows the user to remotely configure AXIS GridLink Controllers without logging on to the server. The utility only needs to be installed on one machine, either outside the farm or on one of the servers on the farm.
Please note the the administrator rights are required to manage GridLink service on the servers. If the user account under which he/she run the utility doesn't belong to the local administrator's group on the servers, the user can still run the utility to view server list, deploy AXIS versions, check job status, change farm settings, etc., however, he/she would not be able to install, uninstall, start, stop and check GridLink service status on the servers.
Farm Profiles and Profile Host
A farm profile is a collection of configurations including the list of server computers on the processor farm and settings for GridLink controllers running on the servers. Farms are managed by GridLink Utility program, and multiple farm profiles are saved in one server with a licenced controller running. This server is called a Profile Host.
Upon start-up of the GridLink Utility, the user is required to provide a password to retrieve all farm profiles from the Profile Host. The default password is "Admin".
All options, e.g. AXIS installation path, batch status update rate, etc., can be configured by the utility. Some options, such as TCP port number and password, are crucial for the utility to connect to the Profile Host and controllers on the farms. Therefore, they cannot be configured by the utility.
Due to the nature of a Windows Service, there's no user interface available for users to change to TCP port or reset the password. In the case that the user needs to do so, he/she can run a tool "AXIS GridLink Service First Aid" (FirstAid.exe), which is located under GridLink installation directory.
Use AXIS GridLink Utility to Mange Server Farms
GridLink Utility is password-protected for security purpose. The default password is "Admin" (case-sensitive) and can be changed with the utility. (Please see "Change Password" for more details.).
The utility connects to the Profile Host, which validates the password, and sends farm profiles currently saved on the host to the utility. If "Connect to all controllers when opening a farm profile" is checked, then when the utility opens a farm profile, it will connect to all controllers running on servers included in the farm. The utility then shows all servers in the current farm, with information about the number of CPU cores, number of licenced helpers, current status, etc. for each server, if the server is being connected.
An alternative way to start GridLink Utility is to use the command line options. The following is the syntax:
GridLinkUtil.exe [-PFHOST:servername] [-PWD:password] [-TCPPORT:portnumber] [-FARM:farmname]
-PFHOST: specify the name of Profile Host
-PWD: specify the logon password
-TCPPORT: specify the TCP port number
-FARM: specify the name of the farm if you have created more than one farm profilee.g. GridLinkUtil.exe -PFHOST:Server1 -PWD:Admin
In the command line, if you have specified both the Profile Host and the Password, and you also specified the Farm Name or there’s only one farm profile, then the logon process will be performed automatically.
If the utility has connected to all controllers in a farm and confirmed that they all have the up-to-date farm profile, then the status of this farm is "ready". Otherwise, the status is "not ready". Please make sure that the farm status is "ready" before it can be used. If the user submits a job to a farm whose status is "not ready", then it may not behave as the user expects.
Please note that if you have 2 farms that share same servers, selecting one farm will affect the status of the other. e.g. If you have a farm "TLAB" that has tlab0, tlab1, tlab2, and tlab3, and another farm "HALF-TLAB" that has tlab0 and tlab1, once you have selected "TLAB" as the current farm, the status of the farm "HALF-TLAB" will become "not ready" because the profile on all servers would be updated with the profile saved as "TLAB".
The icons on the dialog bar are shortcuts for:
On the status bar, the utility shows the maximum number of helpers on the whole farm. It is the summation of licenced helpers on all controllers in the farm.
In the case that a controller is disconnected from the utility, a small red icon will be displayed in front of the server name.
Whenever a profile has been changes (e.g. a new server was added, or some settings have been changed), the profile will be send to all controllers automatically if they are connected, and the user will see the message "Profile was updated successfully" for each controller if the profile was updated. In the case that a profile cannot be updated on a server (e.g. the user tries to remove a server from the farm while a job running on it), an exclamation mark will be displayed in front of the server name.
- Create Farm Profile
At the beginning, no farm profiles are saved on the Profile Host. There are 3 ways to create a new farm profile.
- Create a new farm with empty server list and default settings.
- Create a new farm based on an existing farm profile.
- Create a new farm based on a farm profile retrieved from an existing server.
After a farm profile has been created, the user can add servers into the farm, sort server list, and configure all options using the utility.
- Select Current Farm
The user can create more than one farm profiles and can switch between them by selecting the current farm.
- Delete Current Farm
The user can also delete existing farms. A confirmation is required to perform this action.
To add a new server to an existing farm, the user can either type in a server name or select one from a computer browse dialog.
- Remove Server From Farm
Right-click on a server in the current farm, the user can select "Remove Server From Farm" to remove it.
- Sort Server List by Name
The user may sort the server list in the current farm by server name in ascending order.
- Farm Statistics Information
The user can view the statistics information of the current farm, such as the total number of servers, CPU cores, etc.
The user may use this function to refresh the information about the number of CPU cores, number of licenced helpers, number of running jobs, pending jobs and copies of AXIS on servers.
- Check Job CPU Usage on Servers
The user may use this function to view the current CPU usage for each AXIS copy running on servers.
In the case that the profile was not automatically updated on controllers (e.g. the user tries to remove a server from the farm while a job running on it), the user can try to manually update it later.
- Version Deployment Features
To deploy an AXIS version on a farm, the administrator used to have to log on to each server, run the installation package and answer a number of questions, e.g. the installation path, the password, etc. It is a manual process, which is error-prone and lack of management. e.g. there's no easy way to know which version has been installed on which server.
Now, with AXIS version deployment feature, to install a new version on a farm or uninstall an existing version from a farm is as easy as a few mouse clicks. It is an automated process and is performed from a central place. You can also get the deployment report that lists all versions installed on each server.
After you have downloaded installation files from GGY website, please save them under one directory, and make sure that the file name has the version string appended after "AXIS", e.g. "AXIS11501001.exe".
In GridLink utility, select the menu "Deployment - Install AXIS", then you will see a dialog where you can specify the "AXIS installation file path", where AXIS installation files are stored, and select one or more AXIS version from a "version list", which lists all available versions under that path. Click on "Install" button, and the installation will be performed automatically. This AXIS version will be installed under a temporary directory, then all files will be sent to all servers through the network. Once the installation is finished, the temporary directory will be deleted.
Select the menu "Deployment - Check AXIS Versions", then you will see a list of AXIS versions installed on each server on the farm. If a version has been installed on all servers, the status of this version is "All". It is "Partial" otherwise.
- Uninstall AXIS
Select the menu "Deployment - Uninstall AXIS", then you will see the same list as you have selected "Check AXIS Versions", plus you can select one or more versions in the list and uninstall them by clicking "Uninstall" button.
The same "Deployment" menu items are also available when you right-click on a single server from the main list. The action that you select from this menu will be performed only on the current server.
- Get Servers' System Information
To view the system information (such as CPU, Memory, Operating System, Hard Disk, etc.) of servers in one window.
- Get Free Disk Space
Allows the user to view the free disk space for all drives on all servers. This is very useful for the farm administrator to make sure that all servers have enough disk space to store AXIS files.
- Retrieve Local Log Messages from Servers
Allows the user to get messages logged by controllers without logging on to every machine.
- Suspend/Resume Farm
The user can suspend the farm to perform maintenance if necessary. After a farm is suspended, jobs that have already started on the farm will continue to run, but all pending jobs will stay in pending status until the farm is resumed.
The log on password can be changed by the user.
- Compact Job History Database
The job history database GCDB.mdb includes all historic job records and it will grow bigger and bigger even if some jobs are deleted from the job list. Although GridLink performs the automatic compact on start-up, the user may need to manually compact the database if GridLink has been up and running for a long time.
- View Licence Information
The user can view the licence information on a controller by right-clicking on it. A dialog shows whether the GridLink Module is licenced on the machine, and the number of helpers that the licence permits on this machine to be launched and join the distributed processing.
- Service Management
Now the user can remotely install, uninstall and manage GridLink service on the farm from a central location. Please note that the user needs to have the administrator's right on the servers.
To install the controller service on a server, the user needs to specify the installation path, and a user account under which the service will be run.
If you have already GridLink service installed on a server and want to upgrade the version, you may want to use "Upgrade Service" instead of "Install Service", to make this process easier. The utility will not ask you to provide the service account information. It simply keeps using the existing account.
After GridLink service is installed on servers, the user can uninstall it, check the service status, start/stop the service, and change the service account on servers.
The use can select "Farm Profile - Farm Settings" menu and see all the current farm settings shown in the following tabs.
- Authorized Users
Only authorized AXIS users can use features provided by GridLink module, e.g. submitting jobs to the farm, monitoring remote job status, etc. There are 3 types of users: basic, regular and advanced users.
Basic users can submit jobs to the farm and monitor/manage their own jobs. If the company doesn't allow a user to view jobs submitted by other people, the company should assign this user as a "basic" user.
Regular users can submit jobs to the farm, monitor/manage their own jobs and monitor all jobs in the queue. If the company allows a user to view jobs submitted by other people but doesn't allow him/her to manipulate them, the company should assign this user as a "regular" user.
Advanced users can submit jobs to the farm and monitor/manage all jobs in the queue.
You can add new users into the list or remove users from the list by clicking on "Add" or "Remove" buttons. When adding a new user, you can specify a number of user properties; You can also modify the properties for an existing user by selecting a user and clicking on "Modify" button.
In "Advanced" tab, the farm administrator can specify more properties for the user.
By default, users are able to work with all licenced controllers on the farm. However, consider the following case: a user A from Department A and another user B from Department B are sharing the same farm with 2 licenced controllers. For security reasons, it would be preferable to designate one controller to user A, and the other controller to user B. While both of them will be able to utilize the whole farm (e.g. if there's only one job submitted by user A is running on the farm, this job will use the whole farm), user A will not be able to view the information of jobs submitted by user B, and vice versa. Controller designation can be done by editing user's information.
If you wish to limit the resource priority for jobs submitted by a user, you may specify a "Maximum Resource Priority" for this user. e.g. once you specify it to be "low", all jobs submitted by this user will not get a priority higher than "low". If you don't want to have any priority limit on a user, simply specify this setting as "urgent". It is "high" by default.
If a user wishes his/her remote batch jobs to always use a particular printer, you can specify the printer for this user in the advanced user properties dialog.
Please note that AXIS versions prior to 11.5.02.001 don't support the user authentication feature. The user may want to enforce security for older versions so that users using older AXIS versions will not be able to connect to a controller to submit a job, monitor the job status, and manage the job queue.
In order to launch the AXIS master of the correct version, the controller needs to know the path name where AXIS is installed. When installing AXIS on the server machine, the user needs to append the AXIS version string to the path name (e.g. C:\WinAXIS11401001) so that more than one AXIS version can coexist on the same machine.
The user can choose the format of the AXIS version, which can either have dots (e.g. C:\WinAXIS11401001) or not (e.g. C:\WinAXIS11.4.01.001).
The user can also specify a temporary files path for AXIS master and helpers running on this server. By default the path is "C:\Spare". The controller is responsible of clearing temporary files that may be left by a previous AXIS crash so that they will not accumulate and eventually use up the disk space.
- Network Settings
Exclude IP Addresses - Suppose that the computer where the AXIS master is running has 2 network cards for 2 separate sub-nets, and all helpers are running on the same sub-net, then the network card on the master computer for the other sub-net will not be used to connect to any helper computer participating the distributed processing. Same situation also applies to a helper computer with more than one network card. However, IP addresses of these unused network cards are still exposed to other computers during the distributed processing. Therefore, one computer may try to connect to an IP address on a different sub-net and will report an error message after the attempt fails. When this happens, a helper will take longer time to join the distributed processing than it should.
The user can specify the IP addresses associated with these unused network cards to make the distributed processing more efficient. The user can either add a new address into this list or remove one from it.
Network Services - the network services settings (UDP Ports, IPX Sockets, TCP port, etc) should not be changed unless they conflict with existing network services. If it becomes necessary to change these settings, please ensure that all masters and helpers that will perform distributed processing together have the same UDP/IPX/NetBIOS settings, and all GridLink Controllers have the same TCP port. Otherwise, they will not be able to communicate with each other.
The TCP port used by controllers can be either changed remotely through the utility, or locally on the controller by using "FirstAid.exe".
- Network Drive Mapping
If the AXIS user refers to a shared network folder in his/her batch job (e.g. dataset path, Import/Export database link, a file opened in AXIS script, etc.) with a mapped drive letter, GridLink service needs to have the mapping information in order to access the correct folder. This is be done by specifying the drive mapping information in this tab.
Please note that AXIS remote job will not start if any of the drive mapping applicable to the user didn’t succeed. In the case that there are a few Access Groups created and a mapped drive is only to be used by one of the groups, this drive can be associated with this group, so that this drive will not be mapped when a job is launched under another group.
- Advanced (GridLink)
Resource Priority Ratio
When a job is submitted, it is given a "resource priority" ("urgent", "high", "normal", "low", or "no helpers") which is used to balance helper resources for jobs between 2 queues. Currently, the default ratios for high/normal/low priorities are 100:50:25:5. You can specify your own ratios here.
For more information about "Resource Priority", please click here.
Windows Firewall
Computers might be protected by Windows Firewall, which blocks some communication required to manage the distributed processing feature of AXIS. The user may choose to let the controller to automatically unblock AXIS if it is blocked.
Please note that this feature works for Windows XP SP2 only and the account under which the controller is run requires administrator's right to unblock AXIS.
Remote Jobs Running Simultaneously
The user can controller the maximum number of AXIS remote jobs (i.e. the number of remote batch jobs) running simultaneously on the same server. The maximum value that the user can specify is 4.
AXIS Remote Master Failure Detection
The controller can check the CPU usage of AXIS remote masters and terminate a master if it has been idling for a long time so that the CPU can be released to run other jobs.
The user can specify the time out period from 30 minutes to 300 minutes (5 hours). The user can also choose to disable the detection.
- Advanced (AXIS)
The following advanced parameters are parts of AXIS System Parameters. When AXIS jobs are running on a GridLink farm, these parameters are controlled by GridLink, and can be edited through GridLink Utility.
Subnet
If the user's servers are not sitting on the same subnet, the user needs to turn on "Subnet support" option to ensure the communication between AXIS master and helpers. This setting will override the setting in AXIS system parameters.
Failure Detection Time-out period - A helper that has stopped responding for a certain time period is deemed to have failed. The default value of the time-out period is 1 minute. The user may want to use a longer period if he/she has slow machines. It can be adjusted from 1 to 10 minutes.
Failure Recovery ensures that the master will recover cells that this failed helper has taken but not finished and will redistribute these cells to other machines. Please note that Failure Recovery is not supported in Batch Generate.
Stochastic Processing Memory Usage
Specify the maximum amount of memory (RAM) that can be allocated for each instance of AXIS in Block calculations. For more details, click here.
Formula Table Accelerator
This option has 3 choices:
1. Use the setting received from the job submitter (still allows the user to control this setting. Default.)
2. Enable Formula Table Accelerator for all jobs
3. Disable Formula Table Accelerator for all jobs
- Job Status
Update Speed
When a batch job is running on the server machine, the controller constantly checks its status so that the next job in the queue can start as soon as the current one is finished and the machine becomes available. The controller may need to retrieve detailed information on the batch status dialog from the AXIS master and send it back to a user who is monitoring the batch status from his/her machine.
The user can specify how often the controller refreshes the batch status in seconds. The range is 1 - 60 seconds.
Windows of the AXIS Remote Master/Helper
When a controller runs as Windows service, by default, AXIS master and helper launched by the controller run on an invisible desktop and cannot receive user input. If the user wants to interact with the AXIS window, he/she needs to turn on the option "Make the window of the AXIS remote master/helper visible". (Please note that this option is not supported by AXIS versions prior to 11601001.)
To view the window of AXIS that was remotely launched by GridLink service, the user needs to log on to the console session (session 0) of the server. The command line syntax is shown below:
mstsc -v:servername -console
Once the user has logged on, he/she should not log off if he/she sees any AXIS windows (i.e. a job is running). It is safe to log off if there's no AXIS windows shown.
If the server has move than 4 CPU cores, the user need to either turn on this option or modify the registry to allocate more memory for non-interactive desktop heap. Otherwise, the operating system may run out of non-interactive desktop heap and AXIS will crash. For more information, please refer to Microsoft KB article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;184802
Also, please note that in order to use this feature, the service account must have the local administrator's right.
- Job Records & Logs
Remote Job Records
By default, an authorized user can delete job records if these jobs are not currently running. The farm administrator may stop the user from doing this by disabling "Allow job records to be deleted" option.
Also, the farm administrator can schedule the automatic historic records clean-up if they have finished more than a specified number of days.
Log Controller Activity Messages
When "Log controller activity messages" option is enabled, the activities of clients connecting to the controller will be logged and saved into a text file "Log.txt", which is located under the utility installation directory. Otherwise, only error messages will be saved.
Please note that this file is limited under 1 MB. Old messages will be removed automatically once it reaches the limit in order to log new messages.
- Backup
Starting from version 2.30, the GridLink Utility has introduced a new feature which allow users to backup a farm. For more details, click here.
- Access Group
Access Group feature allows remote jobs submitted by a user to run under this user's credential. This enables different users to have controlled access to different directories when running AXIS jobs. This can be particularly useful when both development and production jobs are being run on the same farm by different users and special protection and restricted access rights are necessary to protect the production datasets and associated directories. For more details, click here.
- Enterprise Grid
GridLink now has been integrated with DataSynapse GridServer and Platform EGO. If you are currently using one of these Grids and wish to have GridLink working with it, you can select "DataSynapse GridServer" or "Platform EGO" from this page.
A number of parameters (e.g. the environment variable DSDRIVER_DIR) need to be specified so that GridLink knows how to connect to the Grid and request CPU cores when AXIS job starts and release them when the job finishes.
We will continue to work with more enterprise grid providers and integrate GridLink with them upon requests from users.
For more information about Grid Computing, please click here.
 |
Contact | | | Send a File to GGY | | | E-mail GGY | Search | |||