Geo Redundancy

XpoLog contains a mechanism that replicates configuration between A Primary and a Secondary sites in order to keep them synchronized for disaster recovery purposes.

The Geo-redundancy mechanism is designed to create a replication of selected XpoLog's configuration between a primary geographical location and a secondary geographical location that XpoLog instance/cluster runs on. In the event of a complete regional outage or disaster in your primary location, if users are redirected to the secondary site, the entire set of configuration will be available identically to the primary site.


XpoLog does not replicate raw data between sites or copies over the configuration files independently. Organizations that wish to activate and use the Geo-redundancy mechanism should have in place a process that copies the raw data to be processed on both sites, and the zipped configuration files created by the Geo-redundancy mechanism on each site to their designated locations on the other site.

The high level logic of the Geo-redundancy mechanism is as follows:
Each site contains an 'Inbox' and 'Outbox' directories. Based on the configured synchronization schedule, XpoLog creates a zipped configuration file which is placed in the site's 'Outbox' directory, and checks if there is a new file in the site's 'Inbox' directory and merges its contents to its local configuration. It is the organization's responsibility on both sites to copy the contents of each site's 'Inbox' directory to the other site's 'Outbox' directory keeping the files last modified time.

Geo-redundancy Configuration

On each XpoLog instance/cluster there are 2 files in which determine the synchronization schedule and contents:

  • /.../XPOLOG_CONF/conf/general/configMerge.xml
    This file determine the contents of configuration that will be included in the sync process between sites.
    • InputsInfo
      • filesToKeep - determines how many files XpoLog should keep in its 'Inbox' directory.
      • Includes - the list of local configruation directories that will be included in the zipped configuration files that is created. By default, all user oriented configuration (avaialble in the GUI) are included:
        • /.../XPOLOG_CONF/conf/general/addressbook.xml - connectivity accounts from the address book.
        • /.../XPOLOG_CONF/conf/logsconf/* and /.../XPOLOG_CONF/conf/modules/* - Folders and Logs.
        • /.../XPOLOG_CONF/conf/metadata/* - appTags.
        • /.../XPOLOG_CONF/conf/verifiers/* - monitors.
        • /.../XPOLOG_CONF/conf/usersenv/* - saved searches and user's specifics.
        • /.../XPOLOG_CONF/conf/ui/apps/deploy/* - all applications (including their dashboards and widgets).
        • /.../XPOLOG_CONF/conf/ext/templates/user/* - logs templates.
        • /.../XPOLOG_CONF/collection/conf/system/system.xml - collection policies.
      • Excludes - specify directories to exclude from the above list.
      • BinaryIncludes - handle binary configuration data. Currently relevant only to user's specifics and user's defined templates.
    • OutputInfo
      • filesToKeep - determines how many files XpoLog should keep in its 'Outbox' directory.

  • /.../XPOLOG_CONF/conf/general/configMerge.user.xml
    This file determine the schedule and 'Inbox'/'Outbox' directories location.
    • ScheduleOp - the scheudler settings which determines the frequency of executing synchronization. The only change should be the cron expression.
      Note: commenting the ScheduleOp object pauses the synchronization process (node(s) restart is required).
    • InputInfo
      • path - the absolute path to the site's 'Inbox' directory.
    • OutputInfo
      • path - the absolute path to the site's 'Outbox' directory

Geo-redundancy Activation

Activation of Geo-redundancy is divided to 2 steps. There is a need to run an initial replication (baseline) so both sites will be synchronized, afterwards the on going synchronization process takes place.
It is mandatory to go through the baseline process and validate it prior to activating the on going sync in order to a valid synchronization process and to avoid configuration duplications.

  1. Geo-redundancy baseline creation
    1. Prerequisite: 
      1. Primary site contains configuration and Secondary site is empty from all configuration.
      2. Disable Geo-redundancy on both sites.
      3. Stop XpoLog instance/cluster on both sites.
    2. Manually copy the directories /files that are part of the sync from the Primary site to the Secondary site (override existing):
      1. /.../XPOLOG_CONF/conf/general/addressbook.xml
      2. /.../XPOLOG_CONF/conf/logsconf/* and /.../XPOLOG_CONF/conf/modules/*
      3. /.../XPOLOG_CONF/conf/metadata/*
      4. /.../XPOLOG_CONF/conf/verifiers/*
      5. /.../XPOLOG_CONF/conf/usersenv/*
      6. /.../XPOLOG_CONF/conf/ui/apps/deploy/*
      7. /.../XPOLOG_CONF/conf/ext/templates/user/*
      8. /.../XPOLOG_CONF/collection/conf/system/system.xml
    3. StartXpoLog instance/cluster on both site and validate that all the configuration is available and identical.
  2. On going synchronization first activation
    1. Prerequisite: 
      1. Baseline procedure complete and validated.
    2. Ensure the files /.../XPOLOG_CONF/conf/general/configMerge.xml and /.../XPOLOG_CONF/conf/general/configMerge.user.xml are properly configured on each site with the correct local path of each site to its 'Inbox' and 'Outbox' directories, scheduler, sync contents, etc.
    3. Ensure on each site that its 'Inbox' and 'Outbox' directories are available and empty.
    4. Enable Geo-redundancy on both sites.
    5. Ensure there's a process in place that copies:
      1. Raw data from Primary site to Secondary site to the required location.
      2. Each site's contents of 'Outbox' to the other site's 'Inbox' and vice versa (keeping files last modified time).
  3. Once the procedure is completed and active, all changes that will be made on any of the sites will be synced to other site. 
    Configuration changes of the same object in XpoLog should take place on one site only and the Geo-redundancy mechanism will sync and merge them in the other site (keep in mind: if the same object is modified on both sites, the last change will be applied based on the file's last modified time).



Important: