MID サーバーのアップグレード
MID サーバーを手動でアップグレードするか、インスタンスから自動的にアップグレードします。インスタンスがアップグレードされ、MID サーバーのバージョンが同じでなくなると、MID サーバーの自動アップグレードがトリガーされます。新しい MID サーバーパッケージが install.service-now.com からダウンロードされ、古いパッケージが置き換えられ、MID サーバーが新しいバージョンで起動します。
MID サーバーのアップグレード要件
- MID サーバーのダウンロード サイトへのアクセス
- MID サーバーのホストコンピューターは、自動でアップグレードするために install.service-now.com の ServiceNow ダウンロードサイトにアクセスできる必要があります。ダウンロードサイトへのアクセスをブロックする自己ホスト ServiceNow 環境の場合は、MID Server インストーラーパッケージを MID サーバーのホストに手動でインポートする必要があります。手順については、自己ホストされたナレッジベースの「KB0760123」を参照してください。
- OCSP への MID サーバーのアクセスをブロック
- ファイアウォールとプロキシの構成によって、OCSP Entrust サーバーと DigiCert サーバーへの呼び出しがブロックされ、MID サーバーが機能しなくなる可能性があります。OCSP トラフィックが通過するように、ファイアウォールの権限を変更する必要がある場合があります。詳細と解決策については、HI ナレッジベースの記事 [KB1216223] を参照してください。
- MID サーバーのオペレーティングシステムの互換性
- 32 ビットのオペレーティングシステムを使用した Windows または Linux MID サーバーのアップグレードはサポートされていません。詳細については、[KB0863694] を参照してください。
Windows アプリケーションエクスペリエンスサービスがオフになっている場合、Windows ホストでは MID サーバーをアップグレードできません。表示されるエラーおよびこのサービスを再度有効にする方法については、KB0597552 を参照してください。
MID サーバーのアップグレードは、Windows ホストで実行されている一部のアンチウイルスによってブロックされています。エラーとこれらのアンチウイルスリストの詳細については、KB0870329 を参照してください。
Madrid 以前のシステムでサービスがインストールされている Linux MID サーバーのアップグレードは、アップグレード後にサービスを再インストールする必要があります。以前のアップグレードでサービスを手動で再インストールしておらず、MID サーバーサービスが引き続き Madrid 以前のバージョンでインストールされると、アップグレード中に MID サーバーによってサービスが自動的に再インストールされます。サービスを再インストールするには、MID サーバーを admin ユーザーとして実行する必要があります。MID サーバーのアップグレードでサービスを再インストールする必要がある場合は、MID サーバーのユーザーが admin であることを確認してください。そうでない場合は、アップグレード前にサービスを手動で再インストールできます。サービスを手動で再インストールする方法については、KB0821436 を参照してください。
MID サーバーをアップグレードする必要のあるタイミング
インスタンスのバージョンと異なるバージョンの MID サーバーは、アップグレードする必要があります。次の 2 つのシステムプロパティが、すべての MID サーバーのバージョンを管理します。
- mid.buildstamp：ビルドの日付に基づく識別子で MID サーバーのバージョンを識別します。このプロパティは、mm-dd-yyyy-hhmm という形式を使用します。MID サーバーは、1 時間ごとにバージョン情報を確認します。上書きバージョンが設定されていない場合、MID サーバーは使用するバージョンの mid.buildstamp プロパティを調べます。このプロパティは、インスタンスの再起動時またはアップグレード時にデフォルト バージョン (インスタンス バージョンと一致するバージョン) にリセットされるため、その時点でユーザーによる変更は失われます。リリース名とパッチ情報が日付と時刻の形式に追加されます。警告:このプロパティはデフォルトでは表示されず、構成する必要があります。
- mid.version.override：環境内のすべての MID サーバーに対して、現在のバージョンの上書き条件を設定します。このアクションは、MID サーバーを単一のバージョンに固定し、自動アップグレード機能を無効にします。このプロパティはベースシステムでは表示されず、設定するときはシステム プロパティ [sys_properties] テーブルに追加する必要があります。詳細については、「Add a system property (システムプロパティを追加する)」を参照してください。
MID サーバーは、1 時間ごとにバージョンを確認するときに、まず mid.version.override プロパティを調べます。このプロパティが空の場合、MID サーバーは mid.buildstamp プロパティからバージョン情報を取得します。上書きバージョンが設定されている場合、MID サーバーはその値を使用し、mid.buildstamp プロパティのバージョン情報は無視します。この上書き値はインスタンスが再起動されても残り、MID サーバーに渡されます。mid.version.override プロパティの値はアップグレード中に消去されます。これにより、MID サーバーが mid.buildstamp プロパティのバージョンに自動的にリセットされます。
MID サーバーのバージョンは、mid.version.override に加えて、MID サーバーを特定のバージョンに固定する設定パラメーター mid.pinned.version で制御することもできます。MID サーバーを固定するには、各 MID サーバーの config.xml ファイルの mid.pinned.version パラメーターをバージョンの名前で設定します。<version>-mm-dd-yyyy の形式を使用します。この設定は、固定される MID サーバーのバージョンのプロパティ設定を上書きします。手順については、「MID サーバーのパラメーターを追加する」を参照してください。このパラメーターに設定された値は、アップグレードの影響を受けません。
アップグレード手法
- 自動
- 自動アップグレードは、インスタンスまたは MID サーバー自体によってトリガーできます。この機能はデフォルトで利用可能です。次の場合に自動アップグレードが行われます。
- インスタンスがアップグレードされ、そのバージョンの MID サーバーが現在 MID サーバー上にあるバージョンと異なる場合。インスタンスは、接続されている MID サーバーに autoUpgrade システムコマンドを送信します。
- MID サーバーは、1 時間ごとにインスタンスをチェックして、アップグレード可能な別のバージョンがあるかどうかを確認します。この時間間隔を変更することはできません。
- マニュアル
- MID サーバーレコードの関連リンクをクリックして、手動でアップグレードを開始します。次の 1 時間ごとの自動更新まで待てない場合や、アップグレードに失敗した後に強制的にアップグレードする場合は、この手法を使用します。手順については、「手動での MID サーバーのアップグレード」を参照してください。
アップグレードの手順
- アップグレード前のチェック：実際の MID サーバーのアップグレードプロセスを開始する前に、MID サーバーは一連のテストを実行して、ホストマシンが最小要件を満たしていることを確認します。この自動テスト中にエラーが発生すると、問題が解決されるまでアップグレードが実行されなくなります。アップグレード前のテストはデフォルトで有効になっていますが、システムプロパティを追加して設定することで無効にできます。詳細については、「アップグレード前の MID サーバーのチェック」を参照してください。
- パッケージのダウンロード：MID サーバーは、install.service-now.com からアップグレードパッケージをダウンロードします。これらのパッケージは zip 形式であり、package/incoming フォルダーの agent フォルダーにダウンロードされます。
- デジタル署名検証
すべてのパッケージをダウンロードした後、 MID サーバーはパッケージのデジタル署名を確認します。検証が失敗した場合は例外がスローされます。エラーは、エージェントログと MID サーバーの問題テーブルに記録されます。
パッケージを手動でダウンロードして置換する場合は、署名を手動で確認できます。インストールまたはアップグレードパッケージの署名を手動で検証するには、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 サーバーは zip ファイルを展開します。
- Rome 以前：オペレーティングシステムで定義された一時フォルダーの下のフォルダーに zip ファイルが解凍されます。フォルダー名はランダムに生成された番号です。オペレーティングシステムの一時フォルダーは、システムプロパティ java.io.tmpdir で指定されます。UNIX ホストでは、このプロパティの値は通常 /tmp または /var/tmp です。
- Rome 以降：MID サーバーは、MID サーバーのアップグレード中にオペレーティングシステムで定義された一時フォルダーの使用を回避します。zip ファイルは、agent フォルダーの下の work/upgrade_temp フォルダー内のフォルダーに展開されます。フォルダー名形式はランダムに生成された番号です。以前の動作に切り替えてオペレーティングシステムで定義された一時フォルダーを使用する場合は、MID サーバーの config.xml ファイルに mid.upgrade.use_os_temp_folder を追加して true に設定します。すべての MID サーバーの動作を切り替えるには、[MID サーバー] フィールドを空白にして、MID サーバーのプロパティ [ecc_agent_property] に動作を追加します。
注:KB0747569 を使用して java.io.tmpdir を変更し、Rome からの今後のアップグレードのためにこれを保持したい場合は、Rome へのアップグレード後に mid.upgrade.use_os_temp_folder を true に設定します。mid.upgrade.use_os_temp_folder が true に設定されていない場合、MID サーバーのアップグレード中に java.io.tmpdir は適用されず、agent\work\upgrade_temp の下のフォルダーが使用されます。 - 古いパッケージをアップグレードされたパッケージに置き換える：アップグレードパッケージをダウンロードして展開した後、MID サーバーは古いファイルを新しいファイルに置き換え、新しいバージョンで起動します。パッケージを置き換えるために、MID サーバーは ServiceNow プラットフォームディストリビューションアップグレード というプロセスを開始し、シャットダウンします。ServiceNow プラットフォームディストリビューションアップグレードは、MID サーバーが適切にシャットダウンするのを待ってから、次のように必要なファイルを置き換えます。
- Rome 以前：このプロセスでは、bin、lib、jre フォルダー内のすべてのファイルとフォルダーが削除され、新しいファイルがこれらのフォルダーにコピーされます。
- Rome 以降：ファイルの新しいバージョンが古いバージョンと異なる場合にのみ、bin、lib、jre 内のファイルが置き換えられます。ServiceNow プラットフォームディストリビューションアップグレード では、アップグレードファイルは消去されず、変更されていないファイルは保持されます。
注:このステップで MID サーバーのアップグレードが失敗した場合、MID サーバーは [ダウン] のままになります。一部のアンチウイルスソフトウェアは、このステップでファイルの置き換えをブロックします。詳細については、KB0870329 を参照してください。
- MID サーバーの起動：必要なすべてのファイルを新しいバージョンに置き換えた後、ServiceNow プラットフォームディストリビューションアップグレードは MID サーバーを起動します。MID サーバーが新しいバージョンを起動すると、アップグレードファイルの抽出に使用されたすべての一時フォルダーがクリーンアップされます。
アップグレード時のログメッセージ
MID サーバーのログメッセージは、次のログファイルで確認できます。
アップグレード前のチェックログメッセージは、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 サーバーのアップグレード中 (Upgrading MID server)」というメッセージはこのステップが開始されたことを示し、「パッケージ PACKAGE.ZIP を EXTRACT_TMP_FOLDER に展開中 (Extracting package PACKAGE.ZIP to EXTRACT_TMP_FOLDER)」というメッセージは、各パッケージの展開を示しています。必要なすべての zip ファイルが正常に展開されると、MID サーバーは ServiceNow プラットフォームディストリビューションアップグレードプロセスを開始し、[MID サーバーを停止しています。アップグレードのブートストラップ中 (Stopping MID server. Bootstrapping upgrade)] メッセージでこのステップが終了したことを示し、その後 MID サーバーが停止します。
- 一時展開フォルダーの 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 サーバーの状況
- アップグレード中
- アップグレードの実行中に、MID サーバーのステータスは、[アップグレード中] に変更されます。[アップグレード中 (Upgrading)] ステータスは、[一時停止] ステータスと似ています。これは、アップグレード中に新しいバージョンのインスタンスと以前のバージョンの MID サーバーとの間で発生する可能性がある通信エラーを回避します。[アップグレード中] 状態の間は、MID サーバーを再開または再起動することはできません。ただし、MID サーバーが [一時停止] 状態のときに実行できるアクションと同じアクションは実行できます。注:Istanbul インスタンスを使用していて、Istanbul 以前の MID サーバーを Istanbul にアップグレードする場合は、これらのアップグレード状況は利用できません。既に Istanbul である MID サーバーにのみ利用できます。
- アップグレード失敗
- アップグレード前のチェックステップまたはパッケージのダウンロード/展開ステップでアップグレードが失敗した場合、失敗したアップグレードはアップグレードしているバージョンに基づいて異なる方法で処理されます。
- 別のメジャーリリースへのアップグレード (Istanbul から次のフルリリースなど)：ステータスが [アップグレード失敗] に変更されます。
- リリース内のマイナー バージョンからのアップグレード (Jakarta パッチ 1 からパッチ 2 など)：MID サーバーは現在実行中のバージョンを使用し続けます。MID サーバーは既に正常に機能しているとみなされ、アップグレードは実行されず、ステータスは最終的に [稼働] に変更されます。
- 最後のステップでアップグレードが失敗し、古いバージョンのパッケージが新しいバージョンのパッケージに置き換えられた場合、MID サーバーは [ダウン (Down)] のままになります。
MID サーバーのアップグレード履歴
MID サーバーのアップグレードに関する問題のトラブルシューティングを行うには、MID サーバーアップグレード履歴モジュールを使用します。モジュールには、各インスタンスのアップグレードのレコードが含まれています。これらのレコードは、各 MID サーバーのアップグレードプロセスの詳細なステータスを段階的に提供します。エラーが発生した場合は、ステップに記載され、詳細が記載されたメッセージが動的に生成されます。テーブルクリーンアップジョブは、ステータスに関係なく、30 日間検出されなかった問題を自動的に削除します。詳細については、「MID サーバーアップグレード履歴」を参照してください。
JRE 更新中の JRE トラストストア証明書の移行
Quebec にアップグレードした後の JRE 更新の場合、MID サーバーは、JRE トラストストア内の既存の自己署名証明書を新しい JRE バージョンのトラストストアに移行します。これらの証明書が移行されると、エイリアスの先頭に文字列「snc_」が追加されます。
証明書を移行するには、次の条件を満たしている必要があります。
- X509 証明書
- 証明書標準 v3
- 基本制約拡張が false に設定されている (つまり、CA が発行されていない)
MID サーバーは、JRE のアップグレードが行われようとしていることを識別し、移行プロセスを開始します。移行前に、MID サーバーは障害発生時のフォールバックとして元のトラストストアのバックアップを作成します。障害が発生した場合は、バックアップのトラストストアを手動で復元できます。