Deployment Scenarios

All references to “location” in this section refer to Configuration Locations. Additionally, all scenarios assume suitable IP/port connectivity to external locations (see earlier).

Create and Manage a Second Virtual Traffic Manager Location

As your services grow in popularity and sophistication, you might want to deploy a second Virtual Traffic Manager presence in some other global location to be run concurrently.

First, perform installation and any initial configuration required by each of the new Virtual Traffic Managers at the new location. Please note however that when joining an existing Virtual Traffic Manager cluster, any non-system specific configuration will be overwritten as the cluster config is replicated to each new machine being added.

From the Admin UI of each Virtual Traffic Manager in turn, run the Join a Cluster wizard to connect to your existing Virtual Traffic Manager cluster.

Either pre-define the new second configuration location on your existing cluster, or specify the “new location” option during step 4 of the wizard. Note that specifying a new location during the wizard will not apply a value to the position setting in the location definition. You must do this manually.

For each subsequent Virtual Traffic Manager, while running the wizard you should ensure you select the newly created location during step 4.

Each new Virtual Traffic Manager will now be added into the cluster, with a copy of the full configuration, but marked as present at the second configuration location. Any configuration changes that were, or are subsequently, made in a location-specific way will be applied across the whole cluster.

Add a New Virtual Traffic Manager to Your Multi-Site Cluster

You can add additional Virtual Traffic Managers to any location managed by the Virtual Traffic Manager by running the Join a Cluster wizard from the Admin UI of the machine you are adding. This will import the configuration of your cluster to your new Virtual Traffic Manager and it will appear as a managed machine within the Admin UI.

Merging Two or More Existing Virtual Traffic Manager Clusters

In normal cluster joining operations, the joining machine takes on the configuration of your cluster, thus deleting any existing configuration you might have had. What we are attempting to do here is to merge two or more distinct configurations so special care must be taken to preserve the settings on all machines.

The Virtual Traffic Manager provides a command line tool “zconf” to perform fine-grained config import/export operations. With this tool we can choose to import the individual services of the secondary clusters into the master cluster config without compromising the existing services. It is also worth making use of zconf’s built-in “dry-run” mode for any import procedures, to ensure that you are fully aware of the expected outcome. For full usage syntax and further information, please refer to the Online Help available directly from zconf.

The intention is to minimize service downtime as best as possible, however it is important to note that there may be service interruptions as Traffic IP addresses are transferred so this is best performed at a time where your Web traffic is at its least.

ATTENTION In all cases, Ivanti strongly recommends that you back up the configuration on all clusters before attempting this procedure. Ivanti also recommends performing the following procedure with a non-critical system first, in order to observe the likely outcome.

To merge two or more existing clusters

Ensure that all your Virtual Traffic Managers in all clusters are running the latest Virtual Traffic Manager software. Designate one cluster as the master cluster.

Set up any new secondary configuration locations on your master cluster.

In order to minimize filename clashes, you may wish to rename your virtual servers, rules, pools, etc., on all clusters to uniquely identify them, such as by pre-pending the location name. For example, renaming “Intranet” to “london-Intranet” and so on. This is not mandatory, however it should reduce the chances of config clashes. The default behavior of zconf is to overwrite existing same-name config files when you perform an import, however this is switchable.

Export your remote cluster configuration using the System > Backups page, and copy the resultant tarball over to your master cluster.

Using zconf, import the virtual servers (/vservers) directory from your config backup. zconf will automatically follow dependencies in each virtual server file and import in the relevant supporting files. The only caveat is the use of Java extensions - you might need to import the /jars and /servlets directories manually.

These imported services should now be marked as enabled only for the newly defined remote location. This can be achieved on the Services > Virtual Server > Edit page by clicking the Edit setting by location icon next to the Enabled setting. Ensure this virtual server is enabled for the remote location and disabled for all other locations.

Use of Traffic IP Groups can cause service conflicts if you have the same IP addresses set up on two clusters. You may need to take the IP addresses in your existing remote cluster offline in order to set up the same IP addresses in your master cluster. As you add in your remote Virtual Traffic Managers to the master cluster, you will need to first remove them from the remote cluster, and as a result, any remote IP groups they appear in first.

Assuming you have multiple Virtual Traffic Manager machines in each cluster, you can disconnect a single Virtual Traffic Manager from each and join it to the master cluster, marked as being at the corresponding defined remote location. Note that system specific settings should be applied directly through the Admin UI of the machine they pertain to.

This Virtual Traffic Manager can be added to the newly created Traffic IP Group and your services should resume.

Now take each remaining remote Virtual Traffic Manager out of the remote cluster and join them into the master cluster, marked as being at the appropriate location and added to the correct Traffic IP Group. Each will inherit the fully merged configuration, and yet will only respond to the services marked for that location.