Multi-Site Support

Companies with multiple sites may decide to implement Monitor at each site instead of monitoring remote license servers across the WAN. Monitor supports two methods of aggregating remote data to a "main" site.

The first method is a sampling method that queries the remote Monitor servers via HTTP. This provides current metrics in the main Monitor site for each remote server being monitored, albeit with a low sampling rate. This approach is good for those who would like to monitor remote sites for license server health and have a high-level view of the usage as well. However, because the sampling rate is low, the granularity of the data collected may not be suitable for running accurate historical reports. Denial data is not supported in this configuration either. If historical report accuracy and/or denial data is of importance, the second method should be considered.

The second method does not sample the remote instances, but instead transfers and loads the remote data files into the main site's database. While this does not provide server health and current usage monitoring, it does provide historical reporting capabilities at the maximum granularity possible.
Note: Currently, it is not possible to employ both aggregation methods due to conflicts that would be created in the main site database.

Method 1: Sampling

Web-based Configuration
The form in the monitor administration web page contains a monitor type for specifying a remote Altair Monitor instance to monitor. The site that is specified will be automatically prepended to the tag so that it will be unique in the main site.
File-based Configuration
To monitor a remote Monitor instance, use add_REMOTE_LM in the licmon.swd/vovlmd/config.tcl file. When using this method, make sure that the tag name is unique and indicates from what site the data originates.

Method 2: Data Transfer

To use this method, there must not be any tag name conflicts between any of the remote sites and the main site. Because of this, it is recommended to include a site identifier in the each tag name. For example, for a main site located in New York, there may be an "EDA_NY" tag to represent the "EDA" license server. If a remote site in San Francisco also has an "EDA" license server, it should be named similar to "EDA_SF". This will allow for both individual and joint reporting in the main site.

To transfer checkout, denial, and capacity data from the remote site to the main site, Monitor relies upon the operating system's task scheduling capability. Once the transfer task is put into place on the remote Monitor server, it will transfer data to the main site per the schedule specified by the administrator. Once the data is transferred, a periodic job is used to load the data automatically into the main site's database.

UNIX Configuration
On UNIX platforms, the cron facility is utilized. The example below uses the UNIX rsync utility specifically, but other file delta-based copy/sync utilities will work as well. The example uses a weekly schedule to perform the data transfer, beginning at 2am every Saturday night. All checkouts data files are transferred into a subdirectory that represents that site from which it originates. The remote site is in San Francisco and the main site is in New York. The main site server name is "nylmsrv".
    # CHECKOUT DATA
    # If main site licmon.swd is available via NFS
    0 2 * * 7 /bin/rsync -az --delete /path/to/SF/licmon.swd/data/checkouts/*.chk.gz \
        /path/to/NY/licmon.swd/data/checkouts/SF

    # If main site licmon.swd is not available via NFS
    # Use as a guide for denial and capacity data as well
    0 2 * * 7 /bin/rsync -az --delete /path/to/SF/licmon.swd/data/checkouts/*.chk.gz \
        nylmsrv:/path/to/NY/licmon.swd/data/checkouts/SF
    
    # DENIAL DATA
    0 2 * * 7 /bin/rsync -az --delete /path/to/SF/licmon.swd/data/denials/* \
        /path/to/NY/licmon.swd/data/denials/SF

    # CAPACITY DATA
    0 2 * * 7 /bin/rsync -az --delete /path/to/SF/licmon.swd/data/capacity/*.cap \
        /path/to/NY/licmon.swd/data/capacity/SF
Note: The example above wraps the configuration line for readability but cron requires each task to be defined entirely on one line.
Windows Configuration
On Windows, the Windows tasks scheduler is used to configure and execute the data transfer task. The example below uses the robocopy utility. Windows Vista, 7, and Server 2008 include this utility, which supports delta-based file copying. On Windows XP, the Windows Resource Kit must be installed in order to have access this utility. In this example, the remote site is in San Francisco and the main site is in New York. The main site server name is "nylmsrv". Using the Windows task scheduler, create a scheduled task to run at the desired schedule using a command syntax similar to:
# CHECKOUT DATA
# If the main site is available via persistent drive letter
robocopy C:\path\to\SF\licmon.swd\data\checkouts E:\path\to\NY\licmon.swd\data\checkouts\SF /MIR /Z

# If the main site is not available via drive letter (use as a guide for denial and capacity data as well)
robocopy C:\path\to\SF\licmon.swd\data\checkouts \\nylmsrv\path\to\NY\licmon.swd\data\checkouts\SF /MIR /Z

# DENIAL DATA
robocopy C:\path\to\SF\licmon.swd\data\denials E:\path\to\NY\licmon.swd\data\denials\SF /MIR /Z

# CAPACITY DATA
robocopy C:\path\to\SF\licmon.swd\data\capacity E:\path\to\NY\licmon.swd\data\capacity\SF /MIR /Z
Automatic Data Loading
To enable automatic loading of the data that is transferred from remote sites into the main site a periodic job is available. The Configuration Information page can be used to configure this task. Refer to the documentation for the LOAD_REMOTE_DATA task for more details.