Blog

How to Set Up a Production SnowMirror

11/01/2018

Back Up ServiceNow Data

In one of the previous posts, we described how to evaluate SnowMirror efficiently. In this article, we give you several best practices on how to install and configure production environment for SnowMirror. Following these best practices will save you some time in the future and help you to avoid issues in SnowMirror operations.

 

Configuration Database

SnowMirror uses two databases. The main database is used for storing the replicated ServiceNow data. The other one contains the configuration data for SnowMirror itself. Please refer to the SnowMirror architecture.

By default the SnowMirror installer or the ZIP distribution configures SnowMirror to use a file-based H2 database. The H2 config database is a good solution for evaluation purposes or for small installations. However, for enterprise and more reliable configurations we recommend to use a traditional relational database (usually of the same type as the mirror database).

If using the Windows installer please select the Custom Installation option and then select the required configuration database type and connection parameters. If installing manually or if you want to make manual modification of the configuration database settings then please edit the snowMirror.properties file.

 

ServiceNow User Account

SnowMirror requires a ServiceNow user account to be able to access the instance. The user account has to have access to ServiceNow meta-data as well as to the data you want to replicate. Using a ServiceNow admin account is a good option for evaluation and test purposes. However, for production deployment we recommend using a special user account with a custom role giving read-only permissions to the required tables only.

Please follow the Admin Guide on how to set up a custom SnowMirror role. Or you can import an XML update set that is being shipped with SnowMirror since version 3.1. Please note that you will still need to set up ACLs to access the data to replicate.
The update set is located in <SNOWMIRROR_HOME>\snow-mirror\monitor\SnowMirrorAgentRole_v1_1_0.xml.

Performance

ServiceNow instance is composed of so-called nodes. A node is basically an application server responding to incoming requests. By default, a typical ServiceNow instance contains just two nodes. However, as your instance becomes bigger and more users access it ServiceNow infrastructure team adds more nodes to the cluster.

SnowMirror can identify individual nodes in the instance and maintain connections with them which results in better performance and higher data throughput.

Please go to Settings -> Performance and use the Discover Nodes button. Then configure the correct number of nodes. Check this settings regularly as the number of nodes evolves over time.

ServiceNow-Side Indexes

IMPORTANT: SnowMirror team and ServiceNow performance experts strongly recommend to introduce ServiceNow-side indexes for tables larger than 100k records. Please create an index for such tables on field sys_updated_on. SnowMirror uses this field to identify incremental changes and a lack of the index results in full table scans which might impair performance of the ServiceNow instance. If using encoded queries (i.e. filters) to replicate subsets of ServiceNow data please consider introducing indexes on fields used by the filter as well.

To create ServiceNow indexes is a straightforward process. We've described it in one of our earlier posts: Working With Database Indexes in ServiceNow.

IndexCreator

 

Responsible Scheduling

SnowMirror is easy to install and configure. It is simple yet powerful but is also means that incorrect or too intensive set up might impact your ServiceNow instance. Please always carefully desigh your replication schedules. Especially configuring periodic synchronizations under 10 minutes might be an issue. Never configure synchronizations to overlap each other. E.g. configuring a replication of a huge incident table containing millions of records every minute if the replication run takes two minutes is a big mistake.

Best practice is to configure replication for most of the tables once a day. These tables usually do not change that often. More important tables can be synchronized once an hour. And only if the requirements are so specific then please carefully select tables to synchronize more often (but never under 10 minutes). Please do not hesitate to ask SnowMirror support for help and experience before configuring intensive replications.

 

Notifications

In Settings -> Notification Management there is a feature to notify you via email if there is any synchronization failure or warning. Please use these notifications to keep your mirror database in a good condition. Optionally you might use the SnowMirror Monitor (i.e. native ServiceNow application) or you can connect your monitoring solution to the REST API.

 

Activity Log Retention

Since SnowMirror 3.2 there is a feature called Activity Log Retention. Please configure this feature in Settings -> General Settings to avoid file system capacity issues and growing configuration database size.  

Share Back