MID Server のアップグレード
MID Server を手動でアップグレードするか、インスタンスから自動的にアップグレードします。インスタンスがアップグレードされ、MID Server のバージョンが同じでなくなると、MID Server の自動アップグレードがトリガーされます。新しい MID Server パッケージが install.service-now.com からダウンロードされ、古いパッケージが置き換えられ、MID Server が新しいバージョンで起動します。
MID Server のアップグレード要件
- MID Serverのダウンロード サイトへのアクセス
- MID Server のホストコンピューターは、自動でアップグレードするために install.service-now.com の ServiceNow ダウンロードサイトにアクセスできる必要があります。ダウンロードサイトへのアクセスをブロックする自己ホスト ServiceNow 環境の場合は、MID Server インストーラーパッケージを MID Server のホストに手動でインポートする必要があります。手順については、自己ホストされたナレッジベースの「KB0760123」を参照してください。
- OCSP への MID Server のアクセスをブロック
- ファイアウォールとプロキシの設定によって OCSP Entrust サーバーへの呼び出しがブロックされ、MID Server が機能しなくなる可能性があります。OCSP トラフィックが適切に動作するように、ファイアウォールの権限を変更する必要がある場合があります。詳細と解決策については、「HI ナレッジベースの記事 [KB0813636]」を参照してください。
- MID Server のオペレーティングシステムの互換性
- 32 ビットのオペレーティングシステムを使用した Windows または Linux MID Server のアップグレードはサポートされていません。詳細については、「 [KB0863694]」を参照してください。
Windows アプリケーションエクスペリエンスサービスがオフになっている場合、Windows ホストでは MID Server をアップグレードできません。表示されるエラーおよびこのサービスを再度有効にする方法については、KB0597552 を参照してください。
MID Server のアップグレードは、Windows ホストで実行されている一部のアンチウイルスによってブロックされています。これらのアンチウイルスのエラーとリストの詳細については、「 KB0870329」を参照してください。
Madrid 以前のシステムでサービスがインストールされている Linux MID Server のアップグレードは、アップグレード後にサービスを再インストールする必要があります。以前のアップグレードでサービスを手動で再インストールしておらず、MID Server サービスが引き続き Madrid 以前のバージョンでインストールされると、アップグレード中に MID Server によってサービスが自動的に再インストールされます。サービスを再インストールするには、MID Server を管理者ユーザーとして実行する必要があります。MID Server のアップグレードでサービスを再インストールする必要がある場合は、MID Server のユーザーが管理者であることを確認してください。そうでない場合は、アップグレード前にサービスを手動で再インストールできます。サービスを手動で再インストールする方法については、「 KB0821436」を参照してください。
MID Server をアップグレードする必要があるタイミング
インスタンスのバージョンと異なるバージョンの MID Server は、アップグレードする必要があります。次の 2 つのシステムプロパティが、すべての MID Server のバージョンを管理します。
- mid.buildstamp：構築の日付に基づく識別子で MID Serverのバージョンを識別します。このプロパティは、mm-dd-yyyy-hhmm という形式を使用します。MID Serverは、1 時間ごとにバージョン情報を確認します。上書きバージョンが設定されていない場合、MID Serverは使用するバージョンの mid.buildstamp プロパティを調べます。このプロパティは、インスタンスの再起動時またはアップグレード時にデフォルト バージョン (インスタンス バージョンと一致するバージョン) にリセットされるため、その時点でユーザーによる変更は失われます。リリース名とパッチ情報が日付と時刻の形式に追加されます。警告:このプロパティはデフォルトでは表示されず、構成する必要があります。
- mid.version.override：環境内のすべての MID Serverに対して、現在のバージョンの上書き条件を設定します。このアクションは、MID Serverを単一のバージョンに固定し、自動アップグレード機能を無効にします。このプロパティはベース システムでは表示されず、設定するときはシステム プロパティ [sys_properties] テーブルに追加する必要があります。詳細については、「Add a system property (システムプロパティを追加する)」を参照してください。
MID Serverは、1 時間ごとにバージョンを確認するときに、まず mid.version.override プロパティを調べます。このプロパティが空の場合、MID Serverは mid.buildstamp プロパティからバージョン情報を取得します。上書きバージョンが設定されている場合、MID Serverはその値を使用し、mid.buildstamp プロパティのバージョン情報は無視します。この上書き値はインスタンスが再起動されても残り、MID Serverに渡されます。mid.version.override プロパティの値はアップグレード中に消去されます。これにより、MID Serverが mid.buildstamp プロパティのバージョンに自動的にリセットされます。
MID Server のバージョンは、mid.version.override に加えて、MID Server を特定のバージョンに固定する設定パラメーター mid.pinned.version で制御することもできます。MID Server を固定するには、各 MID Server の config.xml ファイルの mid.pinned.version パラメーターをバージョンの名前で設定します。<version>-mm-dd-yyyy の形式を使用します。この設定は、固定される MID Serverのバージョンのプロパティ設定を上書きします。手順については、「MID Server のパラメーターを追加する」を参照してください。このパラメーターに設定された値は、アップグレードの影響を受けません。
アップグレード手法
- 自動
- 自動アップグレードは、インスタンスまたは MID Server 自体によってトリガーできます。この機能はデフォルトで利用可能です。次の場合に自動アップグレードが行われます。
- インスタンスがアップグレードされ、そのバージョンの MID Serverが現在 MID Server上にあるバージョンと異なる場合。インスタンスは、接続されている MID Server に autoUpgrade システムコマンドを送信します。
- MID Server は、1 時間ごとにインスタンスをチェックして、アップグレード可能な別のバージョンがあるかどうかを確認します。この時間間隔を変更することはできません。
- マニュアル
- MID Server レコードの関連リンクをクリックして、手動でアップグレードを開始します。次の 1 時間ごとの自動更新まで待てない場合や、アップグレードに失敗した後に強制的にアップグレードする場合は、この手法を使用します。手順については、「手動での MID Server のアップグレード」を参照してください。
アップグレード プロセス
- アップグレード前のチェック：実際の MID Server のアップグレードプロセスを開始する前に、MID Server は一連のテストを実行して、ホストマシンが最小要件を満たしていることを確認します。この自動テスト中にエラーが発生すると、問題が解決されるまでアップグレードが実行されなくなります。アップグレード前のテストはデフォルトで有効になっていますが、システムプロパティを追加して設定することで無効にできます。詳細については、「MID Serverのアップグレード前のチェック」を参照してください。
- パッケージのダウンロード：MID Server は、install.service-now.com からアップグレードパッケージをダウンロードします。これらのパッケージは zip 形式であり、package/incoming フォルダーの agent フォルダーにダウンロードされます。
- デジタル署名検証
すべてのパッケージをダウンロードした後、 MID Server はパッケージのデジタル署名を確認します。検証が失敗した場合は例外がスローされます。エラーは、エージェントログと MID Server の問題テーブルに記録されます。
パッケージを手動でダウンロードして置換する場合は、署名を手動で確認できます。インストールまたはアップグレードパッケージの署名を手動で検証するには、JDK で無料で入手できる jarsigner ツールを使用します。検証を開始する jarsigner コマンドは、
Jarsigner -verify -verbose -certs -strict <zip-file>です。出力は次の例のようになります。- Signed by "CN=ServiceNow Inc., O=ServiceNow Inc., L=Santa Clara, ST=California, C=US" Digest algorithm: SHA-256 Signature algorithm: SHA256withRSA, 2048-bit key Timestamped by "CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US" on Tue Nov 05 19:55:37 UTC 2019 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key jar verified. The signer certificate will expire on 2021-08-09. The timestamp will expire on 2029-03-22. - Zip ファイルの展開：必要なすべてのパッケージをダウンロードした後、MID Server は zip ファイルを展開します。
- Rome 以前：オペレーティングシステムで定義された一時フォルダーの下のフォルダーに zip ファイルが解凍されます。フォルダー名はランダムに生成された番号です。オペレーティングシステムの一時フォルダーは、システムプロパティ java.io.tmpdir で指定されます。UNIX ホストでは、このプロパティの値は通常 /tmp または /var/tmp です。
- Rome 以降：MID Server は、MID Server のアップグレード中にオペレーティングシステムで定義された一時フォルダーの使用を回避します。zip ファイルは、agent フォルダーの下の work/upgrade_temp フォルダー内のフォルダーに展開されます。フォルダー名形式はランダムに生成された番号です。以前の動作に切り替えてオペレーティングシステムで定義された一時フォルダーを使用する場合は、MID Server の config.xml ファイルに mid.upgrade.use_os_temp_folder を追加して true に設定します。すべての MID Server の動作を切り替えるには、[MID Server] フィールドを空白にして、MID Server のプロパティ [ecc_agent_property] に動作を追加します。
注:KB0747569 を使用して java.io.tmpdir を変更し、Rome からの今後のアップグレードのためにこれを保持したい場合は、Rome へのアップグレード後に mid.upgrade.use_os_temp_folder を true に設定します。mid.upgrade.use_os_temp_folder が true に設定されていない場合、MID Server のアップグレード中に java.io.tmpdir は適用されず、agent\work\upgrade_temp の下のフォルダーが使用されます。 - 古いパッケージをアップグレードされたパッケージに置き換える：アップグレードパッケージをダウンロードして展開した後、MID Server は古いファイルを新しいファイルに置き換え、新しいバージョンで起動します。パッケージを置き換えるために、MID Server は ServiceNow プラットフォームディストリビューションアップグレード というプロセスを開始し、シャットダウンします。ServiceNow プラットフォームディストリビューションアップグレードは、MID Server が適切にシャットダウンするのを待ってから、次のように必要なファイルを置き換えます。
- Rome 以前：このプロセスでは、bin、lib、jre フォルダー内のすべてのファイルとフォルダーが削除され、新しいファイルがこれらのフォルダーにコピーされます。
- Rome 以降：ファイルの新しいバージョンが古いバージョンと異なる場合にのみ、bin、lib、jre 内のファイルが置き換えられます。ServiceNow プラットフォームディストリビューションアップグレード では、アップグレードファイルは消去されず、変更されていないファイルは保持されます。
注:このステップで MID Server のアップグレードが失敗した場合、MID Server は [ダウン] のままになります。一部のアンチウイルスソフトウェアは、このステップでファイルの置き換えをブロックします。詳細については、KB0870329 を参照してください。
- MID Server の起動：必要なすべてのファイルを新しいバージョンに置き換えた後、ServiceNow プラットフォームディストリビューションアップグレードは MID Server を起動します。MID Server が新しいバージョンを起動すると、アップグレードファイルの抽出に使用されたすべての一時フォルダーがクリーンアップされます。
アップグレードログメッセージ
MID Server のログメッセージは、次のログファイルで確認できます。
アップグレード前のチェックログメッセージは、agent/logs フォルダーの agent.log ファイルにあります。[アップグレード前の検証テストを実行しています。(Performing pre-upgrade validation tests.)] というメッセージは、 アップグレード前のチェックが開始されたことを示します。すべての必須テストに合格した場合、「アップグレード前の検証テストは成功です (Pre-upgrade validation tests successful)」というメッセージが表示されます。アップグレードプロセスを続行します。(Pre-upgrade validation tests successful. Continuing with upgrade process.)] というメッセージは、アップグレード前のチェックの終了を示します。
ダウンロード時の不足しているファイルのログメッセージも、agent.log で確認できます。すべてのパッケージのダウンロードは、「https://install.service-now.com/ PACKAGEINFO からパッケージを PACKAGENAME.ZIP にダウンロード中 (Downloading package to PACKAGENAME.ZIP from https://install.service-now.com/ PACKAGEINFO)」というメッセージから始まります。ダウンロードの進行状況とダウンロードされたファイルのサイズは、ログで監視されます。すべてのパッケージをダウンロードした後、「パッケージは https://install.service-now.com/ PACKAGEINFO から正常にダウンロードされました (Package was successfully downloaded from https://install.service-now.com/ PACKAGEINFO)」というメッセージで、ダウンロードが成功したことが示されます。
- zip ファイルの展開は、agent.log で利用可能な最後のステップです。「MID Server のアップグレード中 (Upgrading MID server)」というメッセージはこのステップが開始されたことを示し、「パッケージ PACKAGE.ZIP を EXTRACT_TMP_FOLDER に展開中 (Extracting package PACKAGE.ZIP to EXTRACT_TMP_FOLDER)」というメッセージは、各パッケージの展開を示しています。必要なすべての zip ファイルが正常に展開されると、MID Server は ServiceNow プラットフォームディストリビューションアップグレードプロセスを開始し、[MID Server を停止しています。アップグレードのブートストラップ中 (Stopping MID server. Bootstrapping upgrade)] メッセージでこのステップが終了したことを示し、その後 MID Server が停止します。
- 一時展開フォルダーの glide-dist-upgrade.log ファイル。このファイルは、temp 展開フォルダーの下の upgrade-wrapper/logs フォルダーにあります。このログファイルには、プロセスログメッセージとアップグレードログメッセージが含まれています。
- agent\logs フォルダーの dist-upgrade.log ファイル。このファイルには、ログメッセージのアップグレード部分のみが含まれます。プロセスのスタートアップに問題があった場合は、glide-dist-upgrade.log を確認する必要があります。
- Agent\logs フォルダーの wrapper.log。ファイルを置き換えた後、ServiceNow プラットフォームディストリビューションアップグレードは wrapper.logファイルにglide-dist-upgrade.log を追加します。
upgrade-wrapper-override.conf でラッパー構成を更新します
glide-dist-upgrade のラッパー構成は、upgrade-wrapper-override.conf ファイルを使用して更新できます。agent/conf フォルダーに upgrade-wrapper-override.conf という名前のファイルを作成します。upgrade-wrapper-override.conf のすべての構成は、アップグレードプロセス中に使用されます。
upgrade-wrapper-override.conf を使用して設定を変更すると、dist-upgrade ラッパー レベルでデバッグ ログを有効にし、変更をテストできます。
たとえば、デフォルトのタイムアウトは、特定の JVM レベルのコマンドに対して十分に長くない場合があります。タイムアウトは、dist-upgrade ラッパー構成の upgrade-wrapper-override.conf を使用して増やすことができます。
MID Server のステータス
- アップグレード中
- アップグレードの実行中に、MID Server のステータスは、[アップグレード中] に変更されます。[アップグレード中 (Upgrading)] ステータスは、[一時停止] ステータスと似ています。これは、アップグレード中に新しいバージョンのインスタンスと以前のバージョンの MID Server との間で発生する可能性がある通信エラーを回避します。[アップグレード中] 状態の間は、MID Serverを再開または再起動することはできません。ただし、MID Serverが [一時停止] 状態のときに実行できるアクションと同じアクションは実行できます。注:Istanbul インスタンスを使用していて、Istanbul 以前の MID Serverを Istanbul にアップグレードする場合は、これらのアップグレード状態は利用できません。既に Istanbul である MID Server にのみ利用できます。
- アップグレード失敗
- アップグレード前のチェックステップまたはパッケージのダウンロード/展開ステップでアップグレードが失敗した場合、失敗したアップグレードはアップグレードしているバージョンに基づいて異なる方法で処理されます。
- 別のメジャーリリースへのアップグレード (Istanbul から次のフルリリースなど)：ステータスが [アップグレード失敗] に変更されます。
- リリース内のマイナー バージョンからのアップグレード (Jakarta パッチ 1 からパッチ 2 など)：MID Serverは現在実行中のバージョンを使用し続けます。MID Serverは既に正常に機能しているとみなされ、アップグレードは実行されず、ステータスは最終的に [稼働] に変更されます。
- 最後のステップでアップグレードが失敗し、古いバージョンのパッケージが新しいバージョンのパッケージに置き換えられた場合、MID Server は [ダウン (Down)] のままになります。
MID Server アップグレード履歴
MID Server のアップグレードに関する問題のトラブルシューティングを行うには、MID Server アップグレード履歴モジュールを使用します。モジュールには、各インスタンスのアップグレードのレコードが含まれています。これらのレコードは、各 MID Server のアップグレードプロセスの詳細なステータスを段階的に提供します。エラーが発生した場合は、ステップに記載され、詳細が記載されたメッセージが動的に生成されます。テーブルクリーンアップジョブは、ステータスに関係なく、30 日間検出されなかった問題を自動的に削除します。詳細については、「MID Server アップグレード履歴」を参照してください。
JRE 更新中の JRE トラストストア証明書の移行
Quebec にアップグレードした後の JRE 更新の場合、MID Server は、JRE トラストストア内の既存の自己署名証明書を新しい JRE バージョンのトラストストアに移行します。これらの証明書が移行されると、エイリアスの先頭に文字列「snc_」が追加されます。
証明書を移行するには、次の条件を満たしている必要があります。
- X509 証明書
- 証明書標準 v3
- 基本制約拡張が false に設定されている (つまり、CA が発行されていない)
MID Server は、JRE のアップグレードが行われようとしていることを識別し、移行プロセスを開始します。移行前に、MID Server は障害発生時のフォールバックとして元のトラストストアのバックアップを作成します。障害が発生した場合は、バックアップのトラストストアを手動で復元できます。