【ServiceNow】一番シンプルなクローン方法

初めまして。星です。
ServiceNowのクローンのやり方について説明させていただきます。
クローンという方法ひとつ取ってもやり方は様々です。
ここには書かれているのは手法の一つであることにご注意ください。

なぜクローンをする必要があるのか

ServiceNowではライセンス契約を行うと、インスタンスは2つもらうことができます。
一般的には1つを本番環境、もう一方を開発環境として運用することが一般的です。

ServiceNowを使っていると一方のインスタンスをもう一方へクローンする場面があります。
例えばバージョンアップの時です。バージョンアップでは本番環境をいきなりバージョンアップするのはリスクがあるため、一度開発環境へバージョンアップを行い、バージョンアップ後の挙動を確かめることが有効です。

しかし、その際に本番環境と開発環境が全く別の設定では、本番環境が実際にどのような変更が加わるのか確認できなくなるため、十分な効果が得られません。

そのため、開発環境へ本番環境をクローンすることで、「本番環境と全く同じ開発環境」を作成してからバージョンアップを行うことでバージョンアップでの検証をより実際の設定に合わせた状態で行うことができ、バージョンアップの品質が向上いたします。

本番環境をクローン先として指定することはまずないため、
本記事ではクローン元となるソースインスタンスのことを本番環境、クローン先となるターゲットインスタンスのことを開発環境と記します。

前準備

クローンを行う際に設定・確認すべきことがあります。
1.開発環境をクローンして問題ないか
→関係部署と連携を取り、合意を得てください。
2.本番環境、開発環境でMFA認証を必要としないadmin権限を持つユーザを準備。
→MFA認証設定がされていると、ユーザ情報を使ってログインができません。
3. 環境特有の設定、開発中のデータはないか
→該当データがある場合は一時的に更新セットまたはXMLファイルでServiceNow外に保存してください。
※クローンの前後でバージョンが変化してしまう場合は更新セットは適用できないため注意。

クローンの設定

クローン先(開発環境)のシステムプロパティ設定

クローン先(開発環境)にadmin権限ユーザでログインします。
sys_properties.listでシステムプロパティを開きます。
(※デフォルトではシステムプロパティ一覧を開くモジュールはありません)

開いたリストでglide.db.clone.allow_clone_target を検索します。
glide.db.clone.allow_clone_target の値が true となっていることを確認します。
trueでない場合はtrueに変更します。

[推奨作業]
クローン元(本番環境)もadmin権限ユーザでログインし、同様にglide.db.clone.allow_clone_targetを開いて
値がfalse となっていることを確認します。
falseでない場合はfalseに変更します。
※誤って本番環境をクローン先としないための設定なので本番環境はfalseの状態にしてあることが望ましいです。

クローンターゲットの選択

クローン元(本番環境)にadmin権限ユーザでログインします。
システムクローン > クローンターゲット からクローン先(開発環境)の名前のレコードを開きます。

クローンターゲット設定

ユーザ名とパスワードを開発環境インスタンスのadminユーザに変更して更新します。

システムクローン > クローンを要求 を開いて図のように設定します。

プロファイル:空欄
ターゲットインスタンス:クローン先(開発)インスタンスを選択
クローン予定開始時間:クローン処理を開始する日時
※指定した時刻と異なる時刻が設定されることがあるため、送信前に再確認推奨
完了時メール:クローン完了時にメール用を受信するユーザ(メールアドレスを直接入力しても可)
オプション:すべてチェックを入れる。
特定のテーブルからコピーされたデータ:完全

設定が終わったら送信ボタンを押下します。送信時にユーザ認証が要求されるので、クローンターゲット設定で設定したものと同じユーザ名、パスワードを再度入力します。

Warning画面が表示された場合は、内容を確認の上でOKを押下します。
以下画面ショット以外のWarningが表示される場合もあるため、内容を必ず確認してください。

クローン設定確認

システムクローン > ライブクローン > アクティブクローン を開きます。

作業で設定したクローンのレコードを開き、意図した通りの設定になっていることを確認します。

設定した実行時間になるとクローン処理が自動実行されます。

通常、開始から1~1.5時間程度で完了しますが、長引くこともあります。
(筆者はなぜか4時間ほどかかったことがありました。)
クローン中にクローン先(開発環境)インスタンスへログインしないよう徹底してください。

深夜1時~などログインされない時間帯での設定をお勧めします。

クローン処理完了確認

クローンが完了したことをメールで確認します。
下記のようなメールがServiceNowより届きます。

ServiceNow内で完了したことを確認したい場合は、クローン元(本番)インスタンスでシステムクローン >ライブクローン > クローン履歴から該当のクローン履歴を選択すると確認できます。

クローン後作業

事前準備でServiceNow外に保存していた更新セットやXMLをインポートする。

注意

このクローン方法は情報が全てクローンされます。
考えられる注意点の例を以下に記載します。
・クローン元(本番環境)にいなかったユーザは削除され、存在したユーザもクローン先(開発環境)にログインする際のパスワードがクローン元(本番環境)と同じになる
・クローン元(本番環境)に機密情報が含まれる場合、クローン先(開発環境)にも機密情報がクローンされます。

終わりに

今回紹介したのは特殊な設定を行わない、一番シンプルなクローン方法です。
インスタンスごとに「このテーブルはクローンされたくない」「このテーブルはクローンしてしまうと困る」などの要件がある場合もあると思います。その場合はテーブルの徐外設定/保存設定を行うことができるのですが、またそれは機会があれば詳しく説明できればと思います。

著者について
星海地をフォローする

クラウドに強いによるエンジニアブログです。

SCSKでは、自社クラウドと3大メガクラウドの強みを活かし、ハイブリッドクラウド/マルチクラウドのソリューションを展開しています。業界の深い理解をもとに、お客様の業務要件に最適なアーキテクチャをご提案いたします。サービスサイトでは、お客様のDX推進をワンストップで支援するサービスの詳細や導入事例を紹介しています。

ServiceNow
シェアする
タイトルとURLをコピーしました