ServiceNowにおけるインスタンスのClone（クローン）の概要と、挙動が複雑なExcluder（除外設定）・Preserver（保護設定）について解説します。
インスタンスのClone（クローン）とは
Clone（クローン）のイメージ
クローンとは、インスタンス（環境）をコピーすることです。データや設定だけでなく、バージョンやプラグインの適用状況なども含め、まるっとコピーされます。
“インスタンス”については下記の記事で詳しく説明しているので、併せてご参照ください。
Clone（クローン）に使われるのは最新のバックアップデータ
ServiceNowは日次でインスタンスデータのバックアップが取得されており、クローンに使われるのは最後のバックアップです。クローン実行時の断面の情報がコピーされるわけではないという点に注意が必要です。
バックアップの正確な時間は指定できませんが、基本的にはインスタンスの利用の少ない夜間に取得されるため、昨日の深夜の断面が使用されると考えればよいです。
Excluder（除外設定）とPreserver（保護設定）
インスタンスには、外部システムとの接続設定など、インスタンスごとに設定値が異なり、クローン時にデータをコピー・上書きされたくない場合があります。このような場合はソースインスタンスのコピー対象から特定テーブルを除外するExcluder（除外設定）と、ターゲットインスタンスの上書きされたくないデータを保護するPreserver（保護設定）を利用します。ExcluderおよびPreserverが設定されている場合のクローンの動作のイメージは次の通りです。
（参考: KB0715621: Clone FAQs – Frequently Asked Questions）
Excluder（除外設定）
上図ステップ3において、ソースインスタンスのDB上のすべてのテーブル・データはターゲットインスタンスのDBにコピーされます。その上で、上図ステップ4において、Exclude設定が行われているテーブルはコピーされたデータが消去されるため、結果としてデータはコピーされません。
Preserver（保護）
保護対象のデータは、上図ステップ1においてターゲットインスタンス上からファイルにコピーされ、除外設定の処理が行われた後で上図ステップ5においてファイルから復元されます。
なお、Preserverはテーブル単位ではなくデータ単位の設定となっていますが、KBやDOCSによると大量のデータを保護したい場合はPreserverを使用すべきではなく、データのエクスポート・インポートの活用を検討するようにとの記載があり、必要に応じて対象を絞れるようにしているのだと思われます。
Also, preservers are for preserving key data and not a mass amount of data, if you do preserve mass amounts of data the clone can break or take a very long time to run. Would advise not to preserve mass amounts of data.
KB0715621: Clone FAQs – Frequently Asked Questions
Do not use data preservers to transfer large sets of data, such as user groups. If you must preserve table data, such as users, groups, and roles, consider exporting the records to a file and importing them after cloning.
DOCS: Data preservation on cloning target instances
とはいえ、本記事の後半で紹介している別のKBでは、ユーザ関連テーブルをExcluder/Preserverで設定するようにとの記載もあります。私は何度かユーザ関連テーブルにPreserve設定をしたことがありますが、特にクローンに問題はありませんでした。グループやロールの利用方法によってはGroup Member[sys_user_grmember]テーブルやUser Role[sys_user_has_role]テーブルはレコード数が多くなるので注意が必要かもしれません。いずれにしても、大量データの保護は避けるか、フィルタをかけてレコード数を絞るのがよいでしょう。
ExcluderとPreserverを設定した場合の結果
ExcluderとPreserverを設定しクローンを行った場合、下表の結果になります。クローン時、あるテーブルについてターゲットインスタンスの状態をそのまま保持したい場合は、除隊設定と保護設定の両方を設定する必要があることに注意が必要です。
| 除外設定 | 保護設定 | 結果 |
|---|---|---|
| なし | なし | ・ソースインスタンスのすべてのテーブルのデータはすべてコピーされる ・ターゲットインスタンスのデータはすべて消去される ⇒ ターゲットインスタンスには、ソースインスタンスのデータのみが残る |
| なし | あり | ・ソースインスタンスのすべてのテーブルのデータはすべてコピーされる（保護設定による保護データと同じデータは重複してコピーされない） ・ターゲットインスタンスの条件を満たすデータのみが保持され、他はすべて消去される ⇒ ターゲットインスタンスには、ソースインスタンスのデータとターゲットインスタンスの保護対象のデータが残る |
| あり | なし | ・ソースインスタンスの除外設定がされていないテーブルのデータはすべてコピーされ、除外設定がされているテーブルのデータはコピーされない ・ターゲットインスタンスのデータはすべて消去される ⇒ ターゲットインスタンスには、ソースインスタンスの除外設定がされていないテーブルのデータだけが残る（除外設定がされているテーブルは空になる） |
| あり | あり | ・ソースインスタンスの除外設定がされていないテーブルのデータはすべてコピーされ（保護設定による保護データと同じデータは重複してコピーされない）、除外設定がされているテーブルのデータはコピーされない ・ターゲットインスタンスの条件を満たすデータのみが保持され、他はすべて消去される ⇒ ターゲットインスタンスには、ソースインスタンスの除外設定がされていないテーブルのデータとターゲットインスタンスの保護対象のデータが残る（除外設定がされているテーブルは保護対象データのみになる） |
詳しい挙動は下記のナレッジに詳しくまとめられています。
（参考: KB0717012: Clone results based on Exclusion and Preserver configuration
クローンのユースケース
クローンは前述の通り複数のインスタンスを（除外設定や保護設定を除いてほぼ完全に）同じ状態にすることができるため、次の用途で使われます。
アップグレード（バージョンアップ）やパッチ適用の準備
アップグレード（バージョンアップ）やパッチ適用を行う際には、本番環境に対していきなりアップグレード（バージョンアップ）を行うと、主にカスタマイズした機能についてデグレードが発生し既存の機能が利用できなくなる懸念があるため、まずは検証環境や開発環境でリグレッションテストなどを行うことが多いです。その際に、検証環境や開発環境を一度本番環境と（ほぼ）同じ状態にするためにクローンが使われます。
障害発生時の調査・検証の準備
本番環境で障害が発生した際に、本番環境の現象を検証・開発環境に再現した上で調査・検証を行うためにクローンが使われます。
Clone（クローン）の設定方法
クローンのスケジュールは次のような手順で行います。ポイントは、全ての設定をソースインスタンス側で行うということです。
- ターゲットインスタンスの登録（ソースインスタンス側で行う）
- 必要に応じてExcluder（除外設定）とPreserver（保護設定）を設定（ソースインスタンス側で行う）
- クローンのスケジュール（ソースインスタンス側で行う）
1. ターゲットインスタンスの登録（ソースインスタンス側で行う）
まずは、クローンのターゲットとなるインスタンスをソースインスタンスに登録します。
- メニュー > System Clone(システムクローン) > Administration(管理) > Clone Target(クローンターゲット)を開く
- “New(新規)”ボタンを押下しレコード作成画面を開く
- ターゲットインスタンスのURLとadminロールを持つユーザの資格情報を入力し、”Submit(送信)”を押下
* 指定するユーザはターゲットインスタンスにおいてadminロールを持っている必要があります
* 標準では、本番環境は”glide.db.clone.allow_clone_target”プロパティによりクローン対象に指定することができません
2. 必要に応じてExcluder（除外設定）とPreserver（保護設定）を設定（ソースインスタンス側で行う）
Excluder（除外設定）とPreserver（保護設定）は標準で各種ログテーブルなどある程度のテーブル・データが設定されていますが、必要に応じて追加します。
Excluder（除外設定）
除外設定はテーブル単位で行います。
- メニュー > System Clone(システムクローン) > Clone Definition(クローン定義) > Exclude Tables(除外テーブル)を開く
- “New(新規)”ボタンを押下しレコード作成画面を開く
- 除外対象のテーブル名を指定して”Submit(新規)”ボタンを押下
* 下図の標準の設定の例のようにワイルドカードを使用して複数のテーブルをまとめて設定できます。
Preserver（保護設定）
保護設定はデータ単位（テーブル + 条件）で行います。条件を指定しなかった場合は、そのテーブルの全てのデータが保護対象となります。
- メニュー > System Clone(システムクローン) > Clone Definition(クローン定義) > Preserve Data(データを保存)を開く
- “New(新規)”ボタンを押下しレコード作成画面を開く
- 保護対象のテーブル名および条件を指定して”Submit(新規)”ボタンを押下
3. クローンのスケジュール（ソースインスタンス側で行う）
最後に実際のクローンの設定である、スケジュール設定を行います。
- メニュー > System Clone(システムクローン) > Request Clone(クローンを要求)を開く
- ターゲットインスタンス、開始時刻、オプションを入力し”Submit(送信)”を押下
* Profileは、Optionsの設定やExcluder/Preserverの設定をクローンごとに変えたいときに、その設定を保持しておくための機能ですが、あまり使いません。
* “Preserve users and related tables”は後述の通り、動かないので注意が必要です
Clone（クローン）のFAQ
クローンでよくある質問に対する回答を記載します。
Clone Target（クローンターゲット）の設定時に認証が通らない
Multi-factor Authentication（マルチファクタ認証）を有効化している場合は、ワンタイムパス（OTP）をパスワードの末尾に付与する必要があります。なお、2023年1月時点、adminロールを持つユーザはデフォルトでMFA適用対象になっているため、あえて無効化設定を行わない限り、この対応は必須となります。
開始時刻になったのにクローンが始まらない
開始時刻になったのにクローンが始まらない場合は、まずはタイムゾーンが間違っていないか確認しましょう。
その上で、クローンは設定時間よりも遅れて始まることがそこそこあります。私の経験では、最大15分ほど遅れて始まったことがありました。どうしても始まらない場合はサポートに問い合わせましょう。
“Preserve users and related tables”を設定したのにユーザ関連テーブルが上書きされた
この設定については、下記のKB記事において、この機能は無効化されており、回避策としてユーザ関連テーブルをExcluder/Preserverで設定するようと記載されています。
（参考: KB0753118: The clone functionality “Preserve users and related tables” does not work (generates missing references on tables related to role inheritance) and is now disabled for all clones）
2023年1月Tokyoバージョン現在はまだ表示されていますが、将来のアップグレードにより消える可能性があると思われます。
以上です。
コメント