The Traffic Manager Configuration File System

The Traffic Manager stores its configuration in a series of text files under a tree structure of directories, one per object type. As you make configuration changes through the UI or one of the product APIs, the Traffic Manager’s “Admin Server” management component maintains and updates the files and directories accordingly.

ATTENTION
Unless instructed to do so by your support provider, Ivanti strongly recommends that you do not modify these files directly. They are maintained automatically by the Admin Server and as such your changes can be lost or cause unpredictable behavior in your Traffic Manager deployment. Always use the UI, programming APIs, or zconf utility to make changes.

The core Traffic Manager software reads the config when triggered by an observed update, or on a pre-defined chronological basis, and applies the appropriate logic. Additionally, the Traffic Manager ensures synchronization between itself and all other Traffic Manager instances in a cluster, and replicates out any changes that occur. The following diagram demonstrates the directory structure under the root config directory:

ZEUSHOME/zxtm/conf/

|

+-actionprogs/

|

+-actions/

|

+-activitymonitor/

|

+-auth/

|

+-bandwidth/

|

…

…

…

|

+-vservers/

|

+-zxtms/

 

Each of the sections listed in Configuration Sections typically have a file or directory entry under /conf in this way.

When you add a new object of a particular type, the Traffic Manager creates a new config text file with the same name and stores it under the corresponding sub-directory. For example, it you create a new virtual server called “myvirtualserver”, the Traffic Manager creates a new text file:

ZEUSHOME/zxtm/conf/vservers/myvirtualserver

Each config file consists of lines of key-value pairs, separated by new-line characters, in the following format:

<key> <value>[ <next value>…]

The key refers to some setting or feature, and the value is the item, or list of items, applied to that key. The key and value are separated by whitespace, and where the value is actually a list, each item is again separated by whitespace.

The key might be simple or compound. Compound keys are used to group related settings together, and consist of a common component and subsequent sub-components, separated by a ‘!’ character.

You can add comments into config files, pre-pended by the hash (#) character.

The following is an example virtual server config file (name on disk: ZEUSHOME/zxtm/conf/vservers/Intranet) that demonstrates all of the above features:

# This is an example config file for a

# virtual server named ‘Intranet’

Address *

Enabled Yes

Pool Intranet-pool

Port 80

Protection servprot1

request_tracing!enabled Yes

request_tracing!trace_io Yes

responserules headeradjust test_rule

rules

slm slm-class1

timeout 40

webcache!enabled Yes