クラウドソリューションであるServiceNowが、企業内部ネットワークと通信するための中継サーバーであるMIDサーバーの仕組みについて解説します。
最も重要なことは、発生する通信はMIDサーバー→ServiceNow方向のみで、ServiceNow→MIDサーバーの(企業側から見た)インバウンド通信は一切発生しないことです。
MIDサーバーってそもそも何?
まず、MIDサーバーのMIDとはどういう意味でしょう?
Management, Instrumentation, and Discoveryの頭文字を取ってMIDと略しています。
その名の通り、管理、計測、検出のほかにも外部システムと連携するためにも必要なサーバーです。
ローカルネットワーク内で Windows サービスまたは UNIX デーモンとして動作する Java アプリケーションとなります。
ちなみに、MIDサーバーにはServiceNowの個別のライセンスなどは必要ありません。
![](https://servicenow-lab.com/wp-content/uploads/2022/11/image-17-1024x532.png)
MIDサーバーはなぜ必要なの?
ServiceNowでは、ユーザー・組織情報をインポートするための人事システムとの連携や、他システムと連携した自動化ワークフローの実現、ため込んだチケット情報を分析するツールへのデータ連携など、様々な他システム連携が発生します。
他システムとの連携方式はネットワークの観点で次の4種類に分類できます。
![](https://servicenow-lab.com/wp-content/uploads/2022/11/servicenow-midserver-integration-overview-1024x480.png)
① ServiceNow ⇒ 外部システム(クラウド)
② ServiceNow ⇒ 内部システム(オンプレミス)
③ 内部システム(オンプレミス) ⇒ ServiceNow
④ 外部システム(クラウド) ⇒ ServiceNow
この分類において、MIDサーバーが必要となるのは②のServiceNowから内部システムへアクセスする場合です。(*1)
ServiceNowはServiceNow社のデータセンターでホストされており、企業のネットワークに直接アクセスする機能は持っていません。
さらに、多くの企業ではセキュリティを高めるため、DMZと呼ばれるネットワーク領域の機器を除き、外部ネットワークから内部ネットワークへのインバウンド通信をファイアーウォールで遮断しています。
外部と通信する必要のない内部ネットワークの機器は、基本的にプライベートIPアドレスしか持っていないため、仮にServiceNowがそのプライベートIPアドレスを知っていたとしても通信することができません。
ディスカバリーやサービスマッピングなどを使用する場合は、それら全てにアクセスしたいことが度々あると思いますが、この問題をクリアにする必要があります。
![](https://servicenow-lab.com/wp-content/uploads/2022/11/servicenow-why-cant-access-internal-network-1024x480.png)
これらの問題を解決し、ServiceNowから内部ネットワークの機器へのアクセスを可能にするのがMIDサーバーです。
MIDサーバーは何をしてくれるの?
MIDサーバーを使用することで、ServiceNowインスタンスと外部アプリケーション、データソース、サーバー、サービス間の通信とデータの移動を容易にできます。
MIDサーバーは内部ネットワークに構築します。MIDサーバーはServiceNowが行いたい内部ネットワークへの通信がないかを定期的に確認し、通信要求があればそれを内部ネットワークにて代行します。
![](https://servicenow-lab.com/wp-content/uploads/2022/11/servicenow-midserver-eyecatch-1024x522.png)
内部ネットワークに存在するMIDサーバーが間に入ることで、前述の二つの問題を下記の様に解消します。
MIDサーバーはどうやって通信してるの?
ECC Queue [ecc_queue]
ServiceNowとMIDサーバーとの間で情報をやり取りするためのテーブル(キュー)です。
probe
ServiceNowから内部ネットワークの機器への通信内容です。
対象機器のIPアドレスや送信したいコマンドなどが格納されています。
通信要求時はECC Queueに格納され、その結果もまたECC Queueに格納されます。
AMB (Asynchronous Message Bus)
ECC Queueの変更をリアルタイムでMIDサーバーに伝えるためのエンドポイント(URL)です。
AMBを通じてMIDサーバーは新たな通信要求がECC Queueに格納されたことを知ります。
通信代行の流れ
①通信要求(probe)が発生
②ServiceNowは通信要求をECC Queueに格納
③ECC Queueに変更があると、ECC Queue DB Listenerによってその旨をAMBに通知
④AMBからMIDサーバーに新たな通信要求が発生したことを通知
⑤MIDサーバーがECC Queueを確認し通信要求を取得
⑥MIDサーバーが通信を代行
⑦結果をECC Queueに格納
![](https://servicenow-lab.com/wp-content/uploads/2022/11/servicenow-how-mid-works-detail-1024x573.png)
AMBを用いた通信要求の通知
AMB ClientはAMB Channelと永続的なコネクションを維持することで、リアルタイムで通信要求をMIDサーバーに通知できるようにしているそうです。
ドキュメントには詳細な仕様の記載はありませんが、一般的なLong pollingの場合を用いて仕組みを説明します。
MID ServerはAMBに対して通信要求の有無を確認します。
AMBは通信要求がない場合はすぐに応答せず、ECC Queueの更新が発生するまでコネクションを維持し、更新が発生し次第レスポンスを返します。
一定時間レスポンスがない場合、コネクションを張りなおします。
このようにして常にコネクションを維持することで、リアルタイムに通信要求を通知することができます。
![](https://servicenow-lab.com/wp-content/uploads/2022/11/servicenow-mid-long-polling-1024x562.png)
MIDサーバーとServiceNowの間の定期的な通信
DiscoveryやOrchestrationなどの各機能で行う通信とは別に、MID ServerはServiceNowと定期的な通信をしています。
ServiceNowは定期的にHeartbeat probeを送信し、MIDサーバーの死活監視をします。
MIDサーバーはHeartbeat probeを受け取ると、生存していることをECC Queueに返します。
Heartbeatの間隔は標準では5分に設定されています。
「MID Server Monitor」というScheduled Itemで変更することができます。
MIDサーバーには、ServiceNowインスタンスのバージョンに対応したバージョンが存在します。
MIDサーバーは1時間に一度、接続されているServiceNowインスタンスを確認します。最新のMIDサーバーのバージョンがあればそれに自動アップグレードします。
この際、自動でプロセス再起動がかかることに注意してください。なお、自動アップグレードを停止し、手動アップグレードを行うこともできます。
MIDサーバーはどこに置けばいい?
MIDサーバーをネットワーク内のどこに配置するか、インストールするかは必ず考慮に入れなければいけません。
ServiceNowとしてのベストプラクティスとしては以下のようになっています。
日本国内のシステムを検出・統合したいのであればさほど考慮に入れる必要はないかもしれません。
しかし、グローバルなシステムの場合だとこの辺りも考慮点になってきます。
例えば、アメリカのデータセンターを検出したいのにインドにMIDサーバーを配置することは推奨されません。
MIDサーバーは必ず、ターゲットに物理的に近いだけでなく、ターゲットとの間で利用可能な帯域幅を持つ場所に配置しましょう。
また、ネットワークがDMZを使用し、ネットワークセキュリティプロトコルがネットワーク内からDMZへのポート・アクセスを制限していることがあります。
その場合は、DMZ内のデバイスと通信するために、DMZ内のホストにもMIDサーバーを配置することを検討する必要があります。
MIDサーバーのシステム要件は?
前提として、ServiceNowは将来のリリースで32 bitのMIDサーバーのサポートを打ち切る予定です。
特にこだわりがない限りは、64 bitのMIDサーバーをインストールすることを推奨します。
MIDサーバーには、管理用のWeb UIはなく、ServiceNow経由またはSSH、WMI、RDPのいずれかを介してサーバーにログインしメンテナンスを行います。
細かい要件を解説すると少し見づらくなりそうなので、折り畳みにしますね。
気になるものがあったら展開してみてください。
プロダクト | メモリ容量 | ディスク容量 | CPU | OS | スレッド数 |
Cloud Management Platform (CMP) | 8 GB | 40 GB | 4 Core 2 GHz | 64 bit | 25 |
Operational Intelligence | 12 GB | 52 GB | 4 Core 2 GHz | 64 bit | 25 |
Standard | 5 GB | 40 GB | 4 Core 2 GHz | 64 bit | 25 |
下記のことをしたい場合は、WindowsサーバーにMIDサーバーをインストールする必要があります。
- Windows ベースのサーバーをディスカバリーする
- サービス・マッピング・パターンを実行する
- Windowsデバイスに対してフローを実行する
- Windowsデバイスに対してOrchestrationコマンドを実行する
システム要件
Windows Serverの場合は最小機能要件に加えて、表の要件を満たす必要があります。
Windows Operating System | Windows Powershell |
・Windows Server 2012 ・Windows Server 2016 ・Windows Server 2019 | ver. 3.0 ~ ver. 5.1 |
アカウント要件
MIDサーバーをMSIでインストールする場合は、下記のアカウント要件を満たす必要があります。
- ユーザーは、ローカルシステムまたは管理者レベルのアカウント(ローカル管理者、ドメイン管理者など)ではないこと
- 提供されるサービスアカウントがサービスとしてのログオン権限を持っていること
システム要件
Linux Serverでは、それぞれ下記のバージョン以上である必要があります。
- Linux Red Hat 6 以上であること
- Ubuntu 1404 (Ubuntu 14) 以上であること
- CentOS 6 以上であること
OpenJDK
MIDサーバーインストーラパッケージには、OpenJDK ver. 1.8.0_231がバンドルされています。
インストーラは自動的にOpenJDKを設定してくれるので、追加の設定は特に必要ありません。
このバージョンは 32 bit、 64 bitのどちらのMIDサーバーでもサポートされています。
JRE
MIDサーバーは最低でも、JRE ver. 1.8.0_161を必要とします。
現在の推奨バージョンは 1.8.0_231です。
1.8.0_161よりも低いバージョンを使用している場合、暗号化関連の問題が発生する可能性があります。
MIDサーバーが外部JREを使用するように設定され、JREに互換性がないことが検出された場合、MIDサーバーは代わりにバンドルされているJREを使用します。
これが失敗した場合や、互換性のないJREのバージョンのままだと、MIDサーバーは自動的に停止するためご注意ください。
MIDサーバー
- 100MB以上のネットワークかつ、できるだけターゲットに近い場所に設置すること
- ServiceNowインスタンスにTCP:443で外部インターネットアクセスが可能であること
- 必要なすべてのポートおよびプロトコルを使用してターゲットにアクセスできること
- アップグレードのためにinstall.service-now.comにアクセスする必要がある
- TCP:80でOCSPレスポンダーにアクセスする必要がある
ターゲットデバイス
ファイアーウォールは必要な通信に応じて、TCP:161のSNMP、TCP:22のSSH、TCP:80の HTTPなど、適切なプロトコルとポートを使用してMID サーバーに接続することを許可する必要があります。
ネットワーク・ファイアウォール
MIDサーバーとターゲット・デバイスの間で、接続を許可するように設定する必要があります。
ネットワークがDMZを使用し、セキュリティプロトコルがネットワーク内からDMZへのアクセスを制限している場合、DMZ内のデバイスと通信するために、DMZ内のホストにMIDサーバーを配置する必要があります。
OCSP接続
OCSP(オンライン証明書ステータスプロトコル)は、SSL/TLS証明書の失効ステータスを決定するために使用されるプロトコルです。
証明書が交換され、検証されるとき、MIDサーバーは証明書が取り消され、信頼されるべきではないかを決定する必要があります。
OCSPは、MID サーバーのようなクライアントを使用して、HTTPウェブサイトから証明書を受信することによって動作します。
クライアントは、通常TCP:80を介してOCSPレスポンダーにリクエストを送信します。
OCSPレスポンダーからクライアントへ、証明書が有効であるか、または取り消されたかを返します。
接続するために、MIDサーバーは以下のアクセス権を必要とします。
- servicenow.com
- install.service-now.com
- ocsp.entrust.net (または他のOCSP CA)
SSH
UNIX系マシンで使用されます。
TCP:22を介して通信を行います。
HTTP
OCSPレスポンダーへのアクセスに使用されます。
TCP:80を介して通信を行います。
WMI
Windowsマシンで使用されます。
最初の通信はTCP:135を介して行われます。
それ以降の通信は、指定されていないポートを介して行われます。
その結果、MIDサーバーはすべてのポートでターゲットにアクセスできるようになります。
SNMP
ネットワークデバイスに使用されます。
ほとんどのルーター、スイッチ、プリンター、ロードバランサー、およびその他のネットワーク対応デバイスで使用される一般的なプロトコル。
TCP:161を介して通信を行います。
HTTPS
MIDサーバーからServiceNowインスタンスへのアクセスに使用されます。
TCP:443を介して通信を行います。
RDP
Windowsマシンで使用されます。
TCP:3389を介して通信を行います。
WBEM
CIMサーバーに使用されます。
TCP:5989またはTCP:5988を介して通信を行います。
まとめ
MIDサーバーについてざっくり概要を解説してきました。
なんとなく外部連携するときや、ディスカバリーするときに必要なサーバーだよってことを覚えておけば問題ないです。
気を付けるべき点は、MIDサーバーの機能はリクエストを実行し、処理するためにServiceNowインスタンスに結果を返すのみだということです。MIDサーバー自体は情報を保持しません。
細かいインストールの方法などはまた別の記事で解説します。
コメント