MID サーバーのシステム要件

MID サーバーでサポートされているシステム

Windows Server

Windows ベースサーバーのディスカバリー、サービスマッピングパターンの実行、または Windows デバイスでのオーケストレーションコマンドの実行を行うには、Windows Server に MID サーバーをインストールする必要があります。MID サーバーは、仮想マシンや 64 ビットシステムを含む次の Windows オペレーティングシステムをサポートしています。

Windows Server 2012
Windows Server 2016
Windows Server 2019
Windows Server 2022

Linux

MID サーバーは、仮想マシンと 64 ビットシステムの次の Linux バージョンでサポートされています。

Linux Red Hat 6 以降
Ubuntu 1404 (Ubuntu 14) 以降
CentOS 7 以降

注: ServiceNow では、32 ビット MID サーバーの新規インストールやバージョン Rome へのアップグレードはサポートされなくなりました。新しい MID サーバーのインストールは、次のオペレーティングシステムの RPM および MSI インストーラーによってブロックされます。

CentOS 7
Windows Server 2008
Windows Server 2008 R2
Windows 8
Windows 10

MID サーバーは ZIP ファイルを使用して任意のオペレーティングシステムに手動でインストールできますが、Windows 10 はサポートされていません。サポートされていない MID サーバーが Rome に自動でアップグレードされると、MID サーバーの問題 (ecc_agent_issue) に問題レコードが作成されます。詳細については、「Supported platform changes for MID Server (MID サーバーでサポートされているプラットフォームの変更) [KB0863694]」を参照してください。

セキュリティ要件

高いセキュリティ基準を満たすために、MID サーバーは ServiceNow® に接続するときに HTTPS トラフィックで x.509 証明書検証を実行します。MID サーバーとインスタンスの間にネットワークアプライアンスまたはプロキシが存在する場合、そのアプライアンスは信頼されている CA によって署名されたデジタル証明書を提示する必要があります。自己署名証明書または内部 CA によって署名された証明書を使用している場合は、証明書を MID サーバートラストストアにインポートしてください。SSL 証明書の追加方法の詳細については、「MID サーバー用の SSL 証明書を追加する」を参照してください。

OCSP 接続要件

Online Certificate Status Protocol (OCSP) は、SSL/TLS 証明書の失効ステータスを決定するために使用されるプロトコルです。証明書の交換と検証が行われると、MID サーバーは証明書が失効していて信頼すべきでないかどうかを判断する必要があります。

OCSP は、MID サーバーなどのクライアントを使用して、HTTP Web サイトから証明書を受信します。クライアントは、証明書を発行した認証局 (CA) によって運用されているサーバーである OCSP レスポンダーに要求を送信します。クライアントに対する OCSP レスポンダーの応答は、証明書が有効であるか、失効しているかを示します。

接続するには、MID サーバーに次のアクセス権が必要です。

*.service-now.com または <instance_name>.service-now.com
install.service-now.com
http://ocsp.entrust.net
http://ocsp.digicert.com (または他の CA OCSP レスポンダー)

SSL/TLS 証明書は常に有効期限付きで発行されますが、特定の状況では、証明書が期限切れになる前に失効する必要があります (たとえば、関連付けられた秘密キーが侵害された場合など)。したがって、Web サイトの証明書の現在の有効性は、有効期限に関係なく常にクライアントが確認する必要があります。

証明書の失効ステータスを確認できない場合、クライアントは接続に失敗します。ファイアウォールとプロキシの設定によって OCSP Entrust サーバーおよび DigiCert サーバーへの呼び出しがブロックされ、MID サーバーが機能しなくなる可能性があります。OCSP トラフィックが動作するように、ファイアウォールの権限を変更することが必要な場合があります。詳細と解決策については、HI ナレッジベースの記事 [KB1216223] を参照してください。

PowerShell 要件

MID サーバーには、PowerShell の最低バージョン 3.0 が必要であり、PowerShell 5.1 までのバージョンがサポートされています。PowerShell 要件の詳細については、Microsoft のドキュメントを参照してください。インスタンスを使用して現在の PowerShell バージョンを検索するには、ecc_agent_list.do に移動します。[カスタマイズリストの更新] ギアアイコンを使用して、[選択済み] 列に [ホスト PowerShell バージョン] を追加します。次に、PowerShell バージョンで MID サーバーのリストをソートして、古い MID サーバーを探します。または、ホストの PowerShell コンソールでコマンド $Host.Version を使用して、ホストマシンで PowerShell バージョンを検索することもできます。PowerShell バージョンは PSVersion としてリストされます。

Java バージョンのサポート

Java 17.0.12 は MID サーバーインストーラーパッケージにバンドルされていて、新しいすべての MID サーバーのホストにインストールされます。このインストーラーは、使用している環境で実行できるように Java 17.0.12 を自動で設定します。追加の構成は必要ありません。このバージョンは、64 ビットの Windows MID サーバーと Linux MID サーバーの両方をサポートしています。MID サーバーには最低でも JRE バージョン 17.0.10 が必要であり、推奨バージョンは 17.0.12 です。17.0.10 よりも前のバージョンを使用している場合は、暗号化関連の問題が発生する可能性があります。

テストの結果、MID サーバーは、Oracle Java 11 バージョン 17.0.10 で期待どおりに動作することがわかりました。JRE を別のバージョンにアップグレードする必要がある場合は、適切なアカウント担当者に連絡してサポートを受けてください。

アップグレードした MID サーバーでは、オペレーティングシステムのバージョンに応じて異なる Java バージョンを使用する可能性があります。

以前のバージョンからアップグレードした MID サーバーは、MID Server インストーラーに付属する OpenJDK を使用します。OpenJDK のこのバージョンは、これらの MID サーバーで使用するようにテストされ、認定されます。
その他のバージョンのオペレーティングシステムでアップグレードされた MID サーバーは、JRE をインストールパッケージで提供されているバージョンに自動的にアップグレードします。

注: Linux MID サーバーでは glibC バージョン 2.17 が必要です。ライブラリーは JRE 11 用に更新する必要があります。64ビットの Linux システムでは、32 ビットの GNU C ライブラリ (glibc) をインストールする必要があります。CentOS のインストールコマンドは yum install glibc.i686 です。

MID サーバー JRE ダウングレードのサポート

ServiceNow® インスタンスが Quebec からダウングレードされると、MID サーバーもダウングレードされます。ただし、インスタンスが次のいずれかのパッチにダウングレードされる場合を除き、JRE はダウングレードできません。

New York パッチ 12
Orlando パッチ 9
Paris パッチ 3

MID サーバーが Quebec から指定されたパッチとは異なるパッチにダウングレードされた場合は、「Install Java 11 on MID Servers (MID サーバーへの Java 11 のインストール) [KB0752451]」の手順に従ってください。

Java Service Wrapper

MID サーバーのインストーラーには、Tanuki Software Java Service Wrapper バージョン 3.5.40 が含まれています。

JVM メモリサイズの設定

MID サーバーは、1 GB の JVM メモリを備えてインストールされます。製品の推奨メモリサイズが 1 GB を超える場合は、デフォルト設定を上書きする手順について、「MID サーバーの JVM メモリサイズを設定する」を参照してください。

展開タイプ

インスタンスのシステム要件は、MID サーバーが必要な個々の製品のニーズによって決まります。ヘルスログアナリティクスなどの一部のアプリケーションでは、ドキュメントに追加のシステム要件が記載されています。

標準的な展開

次の製品は、MID サーバーが同じ最小ディスクスペースとメモリの要件を共有するため、「標準的」とみなされています。

ディスカバリー
イベント管理
統合
オーケストレーション
サービスマッピング

最小標準要件は、単一の製品と製品を組み合わせた展開の両方に関係します。ディスクまたはメモリの要件を大幅に増やすことなく、複数の標準製品用に単一の MID サーバーを展開できます。

高リソース展開

Cloud Management Platform (CMP) とオペレーショナルインテリジェンスは集中的に処理されるため、標準製品よりも多くのリソースが各 MID サーバーに必要となります。これらの製品用の MID サーバーは、他の製品用の MID サーバーをサポートしない専用ホストにインストールします。

推奨される MID サーバーの最小要件

MID サーバーのパフォーマンスとシステム要件は、以下のような複数の要因によって左右されます (以下のみに限定されるものではありません)。

顧客インフラストラクチャのサイズと MID サーバーで実行するように構成されている特定の機能 (機能)。
ホストにインストールされている MID サーバーの数。
MID サーバーあたりのスレッド数。
MID サーバーホストで実行されている他のアプリケーションの数と性質。
ServiceNow リリースでのアーキテクチャとデザインの強化。たとえば、Orlando で PowerShell for Windows ディスカバリーを使用したり、Quebec でデフォルトの Java ガベージコレクションポリシーを変更したりするなど。

要するに、どんな MID サーバー展開でもうまく機能する単一のサイズ要件はありません。次の文書化されたサイズ変更のガイドラインは、展開の開始点として使用できます。ただし、MID サーバーのパフォーマンスとリソース使用率を継続的に監視し、必要に応じて MID サーバーを調整およびスケールアップしていく必要があります。

MID サーバーの最小システム要件

MID サーバーに必要な最小 CPU 構成は、単一の MID サーバーが展開され、25 の同時スレッドの標準構成を備えた Windows Server 2012 R2 ホストの場合、速度が 2 GHz 以上のクアッドコアプロセッサーです。

MID サーバーの CPU 使用率

ディスカバリーなどのほとんどの MID サーバーアプリケーションは、パフォーマンスを最大化して MID サーバーのリソース使用率を最大化するように設計されています。その結果、MID サーバーがディスカバリースケジュールまたは同様のアプリケーションを実行しているときに、90 〜 100 ％の範囲の非常に高い CPU 使用率セグメントが見られることがあります。

CPU 使用率が非常に高いセグメントは、スループットを最大化するアーキテクチャ設計に沿っていることから生じており、ディスカバリーのパフォーマンスにマイナスの影響を及ぼすことはないため、心配する必要はありません。ディスカバリーの実行が正常に停止すると、MID サーバーホストのリソース使用率は自動的に通常に戻ります。

複数のセグメントの CPU 使用率が非常に高い状態が頻繁かつ長期間にわたり継続する場合は、次のことを避ける必要があります。

MID サーバーで、ディスカバリースケジュールの重複など、アクティブな作業負荷を同時に処理することが予想される場合に、同一ホスト上で複数の MID サーバーを実行する。
MID サーバーホストを他のアプリケーションと共有する。
純粋に CPU 使用率に基づくパフォーマンスアラートを MID サーバーホストに対して設定する。これらのアラートは、必要に応じて、他のパフォーマンスモニターと組み合わせて使用する必要があります。

MID サーバーホストでの追加のパフォーマンス監視の構成

MID サーバーの CPU 使用率はホストの負荷を示す良い指標ですが、可視化は限られています。Windows オペレーティングシステムのシステムプロセッサーキューの長さと UNIX オペレーティングシステムの負荷平均を使用した監視の追加は非常に重要です。

プロセッサーキューの長さ (Windows OS)：準備はできているものの、別のアクティブなスレッドが原因で、現在プロセッサー上で実行できないスレッドの数。キュー内のスレッド数が連続した期間プロセッサーコア数の 2 倍を超える場合、プロセッサーのボトルネックが発生することがあります。
負荷平均 (Unix OS)：定義された期間における Linux サーバーの平均システム負荷。実行中のスレッドと待機中のスレッドの合計を含むサーバーの CPU デマンドです。通常、top コマンドまたは uptime コマンドは、サーバーの負荷平均を出力します。

MID サーバーの CPU パフォーマンスの事例

最大スレッド数の変更が MID サーバーの CPU 使用率に及ぼす影響

内部ベンチマーキングに基づいて、10,000 台のサーバーでクラウドディスカバリーを実行しているときの MID サーバーの CPU 使用率のサンプルデータを以下に示します。スレッドを追加すると、平均 CPU 使用率と最大プロセッサーキューの長さが向上します。

これらのテストでは、最大 CPU 使用率は、スレッド数や OS とは関係なく 100 ％であることが確認されました。平均 CPU 使用率はスレッド数に比例することが確認されました。スレッド数を増やしても、必ずしも直ちに CPU に負荷がかかるわけではありません。プロセッサーの最大キュー長で示されるように、スレッド数をデフォルトの 25 から 50 に増やしても、追加の CPU 負荷は発生しません。ただし、最大スレッド値を 100 に増やすと、プロセッサーキューの長さが大幅に増加し、CPU に負荷がかかっていることを示します。

MID サーバーを他のアプリケーションまたは MID サーバーと共有した場合の CPU 使用率への影響

ディスカバリーの実行は、MID サーバーでは CPU を集中的に使用する操作です。同じホストに他のアプリケーションまたは MID サーバーを展開すると、ホストの CPU 負荷が増えます。この負荷により、MID サーバーを含む実行中のアプリケーションのパフォーマンスが低下します。次の例は、さまざまな負荷パターンを持つ MID サーバーの CPU 使用率データポイントのサンプルです。

単一の MID サーバー専用ホスト：平均 CPU 使用率は 48 ％です。単一の MID サーバー専用ホストでは、平均 CPU 使用率は 48 ％です。

MID サーバーと負荷が中程度の別のアプリケーションで共有されるホスト：平均 CPU 使用率は 77 ％です。

MID サーバーと負荷が大きい別のアプリケーションで共有されるホスト：平均 CPU 使用率は 97 ％です。

MID サーバーと負荷が大きい別のアプリケーションで共有されるホストでは、平均 CPU 使用率は 97 ％です。

MID サーバーのスケールアップと MID サーバーの CPU リソース使用率への影響

MID サーバーで CPU リソースに大きな制約がある場合、CPU を追加して MID サーバーホストをスケールアップすると、リソースの負荷を緩和できます。ただし、これは必ずしも非常に高い CPU 使用率セグメントをなくすものではありません。パフォーマンスを最大化するように設計されたディスカバリーなどの MID サーバーアプリケーションは、引き続き利用可能な追加の CPU リソースを使用します。次の例は、同じディスカバリーディスカバリースケジュールを実行している 4 CPU MID サーバーホストと 8 CPU MID サーバーホストの CPU 使用率データポイントの例です。


パラメーター	4 CPU	8 CPU
平均 CPU 使用率	48 ％	28 ％
最大 CPU 使用率	98 ％	98 ％

4 CPU ホストに展開した場合の MID サーバーの CPU 使用率： 4 CPU ホストでの MID サーバーの CPU 使用率。

8 CPU ホストに展開した場合の MID サーバーの CPU 使用率： 8 CPU ホストでの MID サーバーの CPU 使用率。

パフォーマンスのモニタリング

使用している環境のための MID サーバーのリソース割り当てが十分であることを確認するには、製品実行のピーク期間に MID サーバーダッシュボードからパフォーマンスを監視します。

Yokohama Now Platform 機能