推奨事項
ここでは、Discovery の使用に関するベスト プラクティスと推奨事項を示します。
Discovery/scans フォルダーをインポート フォルダーとして使用しない
If you are using the Discovery Tool on the same server that is running your Jira/Assets service (we do not recommend that), then do not use the scans folder of the Discovery Tool as the import folder.
The import function will create subfolders and handle the imported files in the import folder, which will be in conflict with the Discovery-Tool logic.
Simply create a separate import folder on the server and let Discovery copy the result files to that folder.
Discovery またはコレクターのセットアップ時のエラー メッセージ
エラー メッセージ | この実装は、Windows プラットフォームの FIPS 検証済み暗号化アルゴリズムには含まれていません。 |
---|---|
原因 | この問題は、MD5 アルゴリズムが FIPS に準拠していないために発生します。MD5 アルゴリズムでは、Windows Communication Foundation を使用してハッシュ値を取得します。このハッシュ値から、データ コントラクトの一意の名前が生成されます。 |
ソリューション | この動作を修正するには、次の手順に従います。 3. レジストリ エディターを開いて、次のパスをブラウズします。 HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ ConCtrl\ lsa\ fipsAlgorithmPolicy このレジストリ サブキーが 0 に設定されていることを確認します。 |
The interface is unknown.(HRESULT からの例外: 0x800706 B5)
- Windows Server 2008 R2 を実行するマシンで Discovery インストールをホストしている場合は、Discovery サーバーにこのパッチがないことが問題の原因と考えられます。Windows Server 2008 R2 にはいくつかの既知の問題があります。Service Pack 1 がインストールされており、前述のパッチも適用されていることを確認します。
- Discovery インストールをホストしているマシンが Windows Server2008 R2 を実行しておらず、スキャン エラーが特定の Windows コンピューターに限定されている場合は、これらのクライアント マシンで WMI (Windows Management Instrumentation) が破損している可能性もあります。インストール先サーバーの指示に従って、この問題を修正します。
- WMI 破損エラーを生成しているクライアント マシンで repairwmi.cmd を実行します。%windir%\System32\Wbem\Repository にあるすべての .mof WNI ファイルが再コンパイルされます。
- WMI 破損エラーが発生したクライアント マシンで、以下のコマンドを実行します。
Winmgmt.exe /standalonehost
Winmgmt.exe /resetrepository
- スクリプトで wmidiag がないことが示された場合は、Microsoft WMIDIAG ダウンロードから入手できます。
Windows サーバー 2003 からの製品結果が見つかりません
Windows 2003 Server では、Win 32 _Product は既定では有効になっていないため、次のように有効にする必要があります。
- [プログラムの追加と削除] で、[Windows コンポーネントの追加と削除] をクリックします。
- Windows コンポーネント ウィザードで [管理とモニタ ツール] を選択して、[詳細] をクリックします。
- [管理とモニタ ツール] ダイアログ ボックスで [WMI Windows インストーラ プロバイダ] を選択して、[OK] をクリックします。
- [次へ] をクリックします。
平行スレッドの使い方
CPU コアあたり 2 つのスレッドを使用することで、最高のスキャン パフォーマンスが得られます。
たとえば、2 コアだと 4 スレッド、4 コアだと 8 スレッドのようになります。
1 つのコアに 3 つ以上のスレッドを使用しても、スキャンのパフォーマンスは向上しません。
複数の Discovery インスタンス
Discovery ツールのインスタンスは複数使用できますが、推奨しません。
インスタンスが同時にスキャンを実行すると、スキャンのパフォーマンスに影響する可能性があります。
また、メモリ リークを引き起こし、システム パフォーマンスに影響を与える可能性があります。
1 つのインスタンスを複数のスキャン設定で使用し、平行スレッドを使用する方が効果的です。
スケジュール済みのスキャン設定の重複
スキャン設定を重複させることはできません。
ある設定が実行中のときに別の設定の予定時刻になった場合は、実行中の設定が完了した後に次の設定が開始されます。
大量の宛先システムのスキャン
スキャン可能なシステムの最大数に達した場合で、
スキャン設定を 1 日にわたって分割し、CPU コアごとに 2 スレッドを使用する可能性がある場合は、
別の検出サーバーを作成して、「負荷」をさまざまなスキャン システムに分散させる必要があります。
(同じサーバーに複数の Discovery インスタンスを作成しないでください)
1 日あたりの「スキャン可能」なシステムの最大数
スキャンに必要な時間はさまざまな要因に左右されるため
(たとえば、WMI では、より長い実行時間、インストールされているアプリケーションの数、カスタム パターン、使用可能な CPU コアなどが必要です)
ここで挙げるいくつかの計算はあくまでも例で、ご使用の環境における限界を把握する必要があります。
次の計算は、それぞれの項目に対する経験上の平均所要時間に基づいています。
システム タイプ | 平均時間 |
---|---|
Windows クライアント (20 アプリケーション) | 85秒 |
Windows Server | 45秒 |
Linux クライアント/サーバー | 20秒 |
macOS | 100秒 |
SNMP デバイス | 2秒 |
例の環境での概算:
Windows クライアント | Windows Server | Linux クライアント/サーバー | macOS | SNMP デバイス | 平均時間 | Discovery セットアップ例 |
---|---|---|---|---|---|---|
Windows クライアント | Windows Server | Linux クライアント/サーバー | macOS | SNMP デバイス | 平均時間 | Discovery セットアップ例 |
50 | 20 | 5 | 5160秒 | 1 スキャン サーバー 1 CPU コア 2 スレッド | ||
50 | 50 | 50 | 20 | 7540秒 | 1 スキャン サーバー 1 CPU コア 2 スレッド | |
200 | 150 | 100 | 30 | 50 | 29950秒 | 1 スキャン サーバー 2 CPU コア 4 スレッド |
300 | 500 | 150 | 50 | 20 | 56040秒 | 1 スキャン サーバー 2 CPU コア 4 スレッド |
100 | 100 | 500 | 23000秒 | 1 スキャン サーバー 2 CPU コア 4 スレッド | ||
500 | 1500 | 1500 | 140000秒 | 1 スキャン サーバー 4 CPU コア 8 スレッド | ||
1000 | 2000 | 2500 | 300 | 100 | 255200秒 | 2 スキャン サーバー 2 CPU コア 4 スレッド |
2000 | 2000 | 4000 | 340000秒 | 2 スキャン サーバー 4 CPU コア 8 スレッド | ||
1000 | 3000 | 5000 | 1000 | 500 | 421000秒 | 2 スキャン サーバー 4 CPU コア 8 スレッド |
4000 | 7000 | 4000 | 2000 | 739000秒 | 3 スキャン サーバー 4 CPU コア 8 スレッド |