ITOM Discovery を試すための環境を作るTips

[Shota Nakamura]

ITOM Discoveryを勉強したく、情報を収集される側のCIを用意していきたいと考えています。

それらを（可能なら無料で）用意するための方法/Tipsをご存じの方はいらっしゃるでしょうか？？

[Takuya Kadowak2 · Accepted solution]

Shotaさん、

> (無償ではないですが) AWS, Azure, GCP, OCI等のクラウド上に各種ソリューションテンプレートからインスタンスを作成する → Discovery実施 → CI情報を取得する

上記のように書きましたが、業務アプリケーションのDiscoveryではなく単純にVMのDiscoveryをしたいということであれば、Google Compute Engineの無料枠、Oracle CloudのAlways Freeを使用することも検討してみても良いかもしれません。

各クラウドの無料枠についてまとめたBlogを見つけましたので、参考までに貼っておきます。
https://www.publickey1.jp/blog/20/free_tier2020.html

(下記、念のための免責として記載しておきます)
上記は他社のサービス/サイトになりますので、使用に関しては提供元の情報を確認していただきShotaさんの責任でご判断ください。

[Shota Nakamura]

無償で手に入る系のサーバーだと、そもそもMIDサーバーを動かすスペックに満たないので、
各クラウドの無償枠を使ってDiscoveryを試すのは厳しいことがわかりました。

例えば、
無料で使える範囲のAWS EC2のインスタンスのスペックは メモリ1GB, CPU1コア, ストレージ30GB
一方MIDサーバーでDiscoveryするのに最低限必要なスペックは、メモリ4GB, CPU4コア, ストレージ50GB
(https://docs.servicenow.com/bundle/quebec-servicenow-platform/page/product/mid-server/reference/r_MI...)

自前のPCにMIDサーバー入れて試すのが、無料で行う範囲で一番楽な気がしています。

↓きっとこのような構成になるのでしょう
ServiceNowインスタンス
   └-- 自前PC [ MIDサーバー ⇔ VMware(検出対象) ] 

インフラ屋ではないのでファイヤーウォール等の穴を開ける設定で躓きそうですが、
引き続き調べて試してみます。

[Takuya Kadowak2]

shotaさん、

ご指摘の通りでメモリー容量の視点が抜けてました。

MID Serverのシステム要件にある「RAM 4GB以上」が、サポートできる最小のメモリー容量であることは確かです。

ここから先は、あくまで実験でありお遊びです。

あくまでも学習目的であれば、システム要件を満たしていないサーバーにMID Serverをインストールすることも可能です。

実際にOCIのAlways Free対象である、「VM.Standard.E2.1.Micro」インスタンス(RAM=1GB ※web上の表記。実際には687MBでした。)で試してみました。

(Linux側)MID Serverのインストールと設定は問題なくできました。

(ServiceNowインスタンス側) MID ServerのValidateで問題がありましたが、アプリケーションをDiscoveryに限定して、追加のJAR Filesがないように設定したところValidateできました。(下記のMID ServerがValidatedにならない時の確認ポイントを見てください)

MID ServerをインストールしたLinuxサーバーのDiscovery→できました。
ただし、一回目は失敗しました。
その後で5回Discoveryを実施したところ問題なく完了しました。

Failed Exploring CI Pattern, Pattern name: Linux Server, To Check Pattern Log Press Here

2021-06-26 18:45:54: Identification Engine: Discovery status is FAILURE, Failed to initialize the pattern library. Check that the Mid Server is active and try to restart it.

Linux Serverのディスカバリーパターンの初期化に失敗しているので、顕著にメモリー不足の影響を受けているものと予想されます。/proc/meminfo を見ると703104 kBになってました。

このため、OSの上に他の色々なアプリケーションが動いていたり、IPアドレスレンジでディスカバリーをかけると失敗するかもしれません。

また、あくまで現在のMID Serverのバージョン、Linuxのバージョンでたまたまうまくいっただけなので、基本的にはshotaさんのご認識の通りでリソースが担保されているPCをMID Serverにして、クラウドインスタンスをDiscoveryする対象にするのが良いかと思います。

shotaさんの勉強の参考になることを祈っています。

MID ServerがValidatedにならない時の確認ポイント

MID Serverのメモリーフットプリント(Heap)が最小になるようにします。

1. MID ServerのApplicationを「MID Server」に限定する。

2. MID Serverに追加のJARファイルが転送されないようにする。MID Server > JAR Files を確認して、全部のファイルを削除するか無効にする。

[Shota Nakamura]

Kadowakiさん

追加の調査ありがとうございます！

実は私も無償枠の低スペックサーバーでMIDサーバーが動くか検証していました。

• スペック（Amazon EC2）
• OS：Windows server 2019
• 1コア
• メモリ 1GB
• ストレージ 30GB

検証の結果結果、上記のスペックでもMIDサーバーとServiceNowインスタンスの疎通がとれるところまでは確認できております。
ただしメモリ使用率は常に90％なので、おっしゃる通り、お遊び程度の検証しかできそうにないですね。

肝心のDiscoveryの検証は、プラグインのActivateに失敗しているような状況なので未実施です。
⇒Instance Helpの方で質問中

[Takuya Kadowak2]

その後しばらく回してみて気づいた点があったので追記しておきます。

その後、RAM 687MBだと安定して使えないことが分かりました。さすがにメモリー容量が少なすぎたようです。

MID Server failed to upgrade

というメッセージを残して止まってました。不定期で実施されるMID Server自体のアップデートの時にメモリー不足を起こしてしまったと推測されます。

月額699円でメモリー2GBのUbuntu VMを利用できるサービスがあったのでこちらでMID Serverを立て直しましたが、今のところ使えています。

特定のサービスを推奨するわけではありませんが、ご参考までに。

https://web.arena.ne.jp/indigo/