Hello everyone,
I’d like to share what I’ve learned about instance cloning.
What is it?
The common use of instance clone production environments over dev/test at certain amount of time, to ensure that the development/test teams are working in conditions as close as possible to production environment.
In our case, we leveraged that for much more complex assignment. The case was that the client was splitting into two legal entities and, thus, wanted to have two separate ServiceNow instances. The approach, identified by the architect was to get a fresh instance, to clone the existing production environment over it and the do the necessary clean-up and post-clone configurations.
How the process goes
To make the reading easier, let’s define two key terms:
- Source instance (the one that is used as blueprint)
- Target instance (the one that is going to be the cloning after the process is complete)
To begin the process, create a service account in the target instance. This will be used for authentication when the clone is initiated. (In the target instance)
Then, define a target instance in table instance. For this you will need the instance name and the credentials, created in the previous step. (In the source instance)
Next step is to define clone profile. This includes name, target instance and some more options like if you want to exclude the audit log data, whether to copy the full amount of data or only the one, created in the last 90 days, etc. (in the source instance)
Once done, here comes the funny part – Table Exclusions, Data preservers, Clean-up scripts. (In the source instance)
Table exclusions
Basically, here you can define which table data to be excluded and not copied to the target instance. This means that the table itself and all the configurations will be copied, only the data inside will be skipped.
One important thing here is that excluding a parent table will exclude all the tables that extend from it.
Another important thing is that exclusions can be defined as wildcards. For example, all the tables from scope ‘company_application_…’ can be excluded with a single exclusion record. Please note that the wildcard record has to have a period before the asterisk:
- ‘company_application_*’ is not valid exclusion
- ‘company_application_.*’ is valid exclusion
Data preservers
These records allow you to protect the data in the target instance but are defined in the source instance.
More about how table exclusions and data preservers work together can be found in this nicely explained support article.
Clean-up scripts
These are scripts that are defined in the source instance, but run on the target instance, once the clone process is complete, but before the instance is operational.
There are some out-of-the-box examples, like scripts that disable the system emails to prevent unexpected notifications.
Once you have everything set-up correctly, you can schedule a clone in a convenient time. This will use the last system backup, which is happening usually during the night.
What’s happening in the backstage
When the time comes and the process start, it goes through a set of predefined activities:
- Pre-flight checks – here the system reads the defined exclusions and preservers and checks if there are some issues
- Provisioning a new database for the target instance
- Copying the data from source to the new database of the target
- Applying preservers – whatever is preserved is copied from the old target database to the new one
- Repointing app nodes from the old target database to the new one (Here the instance become unavailable for some period. Up to this point, the target instance is operational)
- Post-clone processing – here is the point where the clean-up scripts get executed.
- Clone complete – instance is released and operational
What you must have in mind
First, depending on the amount of data and configurations, the clone duration may differ significantly. The lowest I’ve seen is 4 hours, the highest – 16+ hours.
During the clone process, you will get two notifications in your email. One for the start, and one when the clone is complete. All the other progress can be tracked in the clone log under the ‘Active clone’ record for the current clone.
After the instance is release, usually the new instance is quite unresponsive (even though this depends highly on the number of application nodes). This is because of indexing, service mapping recomputation, etc.
Voila, you have the clone now!
Since, I’ve identified all this with extensive research and didn’t find some synthesis, I decided to provide such. Please mark helpful and subscribe for my content. This is motivating me to share my findings and knowledge with the Community.
Thanks!
Martin
