プローブからパターンへの移行：プローブベースディスカバリーからパターンベースディスカバリーに切り替える手順Issue このプローブからパターンへの移行プロセスは、New York リリース以降が稼働していて、現在、ディスカバリー用のプローブを使用している顧客に対してのみサポートされます。 目次 概要これらのスクリプトの機能前提条件手順既知の問題FAQ 概要 水平検出パターンは、構成アイテム (CI) を検出するための標準となっています。パターンを使用すると、従来のプローブやセンサーと比較して、検出のデバッグとトラブルシューティングがよりシンプルで直感的になります。 プローブベースディスカバリーとパターンベースディスカバリーでは、CMDB にデータを保存するメカニズムが異なります。両方のディスカバリー方法を併用すると、CMDB のデータが重複する可能性があります。また、パターンベースディスカバリーは関係性に依存しますが、従来のプローブベースディスカバリーは参照を使用します。 プローブベースの水平検出とパターンベースの水平検出の違いの詳細については、製品ドキュメント「Using Patterns For Horizontal Discovery (水平検出にパターンを使用する)」を参照してください。 このプロセスは、New York リリース以降で稼働しているインスタンスのみを対象としています。New York より前のリリースでこの移行を実行しようとすると、無効なデータやデータの重複が発生するリスクがあります。 これらのスクリプトの機能 これらの移行スクリプトは、次のことを行います。 プローブを介して検出されている現在の CI を引き続き識別するために、パターン検出に必要となる適切な関係性を追加します。異なる関係性タイプを持つ、または異なる親/子の値を持つ可能性がある特定の関係性を更新します。適切なディスカバリー分類レコード (discovery_classy) を更新し、パターン関連のプローブを使用するようにトリガープローブレコード (discovery_classifier_probe) を変換します。 前提条件 Orlando リリース以降、ProbeToPatternPrerequisiteScript と呼ばれるスクリプトインクルードがあり、これを使用することで、移行を開始する前にこれらのチェックのほとんどを実行できます。このスクリプトの詳細について、また、このスクリプトインクルードをインポートしてインスタンスで使用する New York のユーザーは、KB0750351 を参照してください。 New York リリース以降、かつ現在 OS 検出にプローブを使用している必要があります。移行中は、すべての検出ジョブとサービスマッピングジョブ、および CMDB データに影響を与える可能性があるインポートジョブを無効にする必要があります。次のスクリーンショットのように、discovery_probes テーブルに水平パターンプローブレコードが含まれている必要があります。 インスタンスには、以下の規定の関係性タイプレコード (cmdb_rel_type) が存在する必要があります。 Runs on::Runs (sys_id: 60bc4e22c0a8010e01f074cbe6bd73c3)Owns::Owned by (sys_id: 25242fb2377a9200738d021a54990e88)Contains::Contained by (sys_id: 55c95bf6c0a8010e0118ec7056ebc54d)Uses::Used by (sys_id: cb5592603751200032ff8c00dfbe5d17)Defines resources for::Gets resources from (sys_id: de5aeb6a0ab3015854626f204fb7b1c0)Virtualized by::Virtualizes (sys_id: d93304fb0a0a0b78006081a72ef08444)Provides::Provided by (sys_id: f67e9ecdff602000dada361332f49d35)Provided By::Provides (sys_id: 4afd799338a02000c18673032c71b817)Members::Member of (sys_id: 55c913d3c0a8010e012d1563182d6050)Registered on::Has registered (sys_id: aa9434870ab301544ce2943bf03fd7a8)注：これらのレコードのいずれかが存在しない場合、または存在するが sys_id 値が異なる場合 (つまり、レコードがカスタマイズされている場合)、その対処方法については、以下の FAQ セクションを参照してください。 以下の分類子レコードが正確な名前で存在する必要があります。 Windows Windows 2000 ServerWindows 2003 ServerWindows 2008 ServerWindows Server 2012Windows 2016 ServerWindows NT ServerWindowsHyper-V Server Unix LinuxSolarisHP-UXAIX SNMP Standard Network RouterStandard Network SwitchF5 BIG-IP Load BalancerA10 Load BalancerAlteon Load BalancerACE Load BalancerNetscaler Load BalancerRadware - AppDirector - Load Balancer プロセス (Orlando で開始) Apache ServerJBoss ServerWeblogic ServerMySQL ServerMicrosoft SQL ServerTomcatMicrosoft IIS ServerPostgreSQL InstanceOracle Instance 注：これらのレコードのいずれかが存在しない場合、またはこれらのレコードの名前が変更された場合、その対処方法については、以下の FAQ セクションを参照してください。 ステップ 4 で説明した分類子については、「プローブのトリガー」リストを確認してください。次のスクリーンショットのように、active = false に設定された水平パターンを実行するための既存のレコードが存在する必要があります。 分類子の一部または全部において、「プローブのトリガー」リストに上記のようなレコードがない場合、必要に応じて修正スクリプトにより分類子を作成できます。 ただし、名前に基づいてリンクできるように、次のパターンレコード (sa_pattern) がインスタンスにあることを確認する必要があります。 Windows Windows OS - ServersWindows OS - DesktopsHyper-V Server Unix Linux Server (以下の例を参照)Solaris ServerHP-UX ServerAIX Server SNMP Network RouterNetwork SwitchF5 Load BalancerA10 Load BalancerAlteon Load BalancerACE Load Balancer by SSHNetscaler Load BalancerAppDirector Load Balancer プロセス (Orlando で開始) Apache On WindowsApache on UNIX based OSJbossWebLogicMy SQL server On Windows and LinuxMSSql DB On WindowsTomcatIISPostgreSQL DBOracle DB On WindowsOracle DB On Unix 注：これらのパターンレコードのいずれかが存在しない場合、またはこれらのレコードの名前が変更された場合、その対処方法については、以下の FAQ セクションを参照してください。 手順 注：Orlando 以降、この移行プロセスを UI で実行できるページが追加されました。詳細については KB0781470 を参照してください。以下の手順は、New York リリースのお客様にのみ適用されます。 これらの変換スクリプトを使用するには、2 つの方法があります。CMDB のサイズに基づいて最適なオプションを選択してください。 注：このプローブからパターンへの移行プロセスは、1 方向で 1 回だけ実行するよう想定されています。プローブの使用に戻すことはサポートされません。戻すことにより CMDB でデータの問題が発生する可能性があるためです。 以下の個々の変換スクリプトを一度に 1 つずつ実行することをお勧めします。例えば、Windows 用のスクリプトから開始する場合は、以下の手順に従います。 [システム定義] > [スケジュール済みジョブ] に移動します。 [スケジュール済みジョブ] テーブルで、[新規] をクリックし、[選択したスクリプトの自動実行] オプションを選択します。このスクリプトには、次の値を入力します。 Name = プローブからパターンに移行：WindowsActive = TrueRun = OnceStarting = [このスクリプトを実行する日時を選択]Conditional = FalseRun this script = var fix = new FixWindowsModelForPatterns();fix.addMissingRelationsForWindows(); [送信] をクリックし、指定された開始時刻にこのスクリプトが実行されるまで待ちます。 これが完了したら、以下の他の CI タイプに対してこのプロセスを繰り返します。 UNIX：Name = プローブからパターンに移行：UnixRun this script = var fix = new FixUnixFamilyModelForPatterns();fix.addMissingRelationsForUnix(); ルーターおよびスイッチ：Name = プローブからパターンに移行：ネットワークRun this script = var fix = new FixSwitchAndRouterModelForPatterns();fix.addMissingRelationsForSwitchesAndRouters(); ロードバランサー：Name = プローブからパターンに移行：ロードバランサーRun this script = var fix = new FixPatternLoadBalancersModel();fix.addMissingRelationsForLoadBalancers(); すべての分類子に対する変換プロセスを 1 つのステップで実行するには、次の手順に従います。 注：これは小規模な CMDB に対してのみお勧めします。 [システム定義] > [スケジュール済みジョブ] に移動します。 [スケジュール済みジョブ] テーブルで、[新規] をクリックし、[選択したスクリプトの自動実行] オプションを選択します。このスクリプトには、次の値を入力します。 Name = プローブからパターンに移行：すべてActive = TrueRun = OnceStarting = [このスクリプトを実行する日時を選択]Conditional = FalseRun this script = FixMissingRelationsFromProbesToPatterns.moveProbesToPatterns(); [送信] をクリックし、指定された開始時刻にこのスクリプトが実行されるまで待ちます。 注：これらのスクリプトを [スクリプト - バックグラウンド] で実行することもできますが、これは小規模な CMDB でのみ推奨されます。 既知の問題 *** Windows での移行中に発生する可能性のある既知の問題として、ストレージデバイスの重複があります。詳細については KB0748332 (要ログイン) を参照してください。*** *** PRB1368993：移行中に「glide.discovery.ip_based.active」が期待どおりに更新されません。その場合は、プロパティ値を手動で false に更新します。*** *** OS パッケージの移行は、Orlando Patch 7 および Paris Patch 1 以降でサポートされています。詳細については KB0827777 (要ログイン) を参照してください。*** *** また、移行で処理されないプローブとパターンの間の既知の差異が、いくつか存在します。詳細については KB0827212 を参照してください。*** FAQ 1) 分類子でカスタムプローブを使用している場合はどうなりますか？それらはどのように処理されますか？ 移行プロセスでは、ディスカバリーを初めて有効にする場合と同様に、パターンを使用するようにインスタンスを設定することを目的としています。 デフォルトでは、移行する分類子に追加されたカスタムプローブはすべて active = false になります。これは、カスタムプローブによって検出されるデータが、パターンによって検出される新しいデータと干渉することによって問題が生じることを防ぐためです。 これらのカスタムプローブは、それぞれの分類子に移動し、トリガープローブレコードを active = true に戻すことで、いつでも再び有効にできます。 2) 前提条件リストにあるデフォルトの関係性タイプレコードの一部がない場合はどうすればよいですか？ スクリプトインクルード FixPatternsModelBasic では、これらの関係性をそのように定義しています。 これらの関係性のいずれかが欠落している場合は、これらのレコードのデフォルトバージョンを再挿入する必要があります。そのためには、欠落しているレコードが削除済みレコードテーブル (sys_audit_delete) に存在するかどうかを確認してから、削除されたレコードを復元します。または、可能であれば、テクニカルサポートに依頼して、規定のインスタンスから欠落しているレコードをインポートする必要があるかもしれません。 これらの関係性のいずれかが存在していても、sys_id 値が異なる場合は、可能であれば関係性のカスタムバージョンを削除し、デフォルトバージョンを復元することをお勧めします。これには、デフォルト値を代わりに使用するように、カスタムの関係性タイプを使用している既存の関係性レコード (cmdb_rel_ci) を更新することも含まれます。 しかし、それが不可能な場合は、この FixPatternsModelBasic スクリプトを手動で更新して、現在のカスタム値をデフォルト値に置き換える必要があります。例えば、Runs on::Runs の関係性レコードがあるものの、sys_id が異なる場合 (例：517ab95338a02000c18673032c71b904)、次のように、この新しい sys_id 値を参照するように該当する変数値を置き換える必要があります。 this.RUNS_ON = "517ab95338a02000c18673032c71b904"; 3) 前提条件リストに記載されている名前の特定の分類子レコードまたはパターンレコードがない場合はどうすればよいですか？(例：Windows 2008 Server ではなく、Windows 2008 Custom というカスタム分類子を使用しています) 個々の「修正」スクリプトインクルード (例：FixWindowsModelForPatterns、FixUnixFamilyModelForPatterns など) で、次のような関数呼び出しを使用して、移行プロセスが分類子をプローブからパターンに変換します。 migrate.enablePattern('windows', 'Windows 2008 Server', 'Windows OS - Servers'); この関数呼び出しは、次の 3 つのパラメーターを渡します。 最初のパラメーターは、ターゲットとする discovery_classy テーブルを識別するために使用されます (例：discovery_classy_windows)。 2 番目のパラメーターは、ターゲットとする分類子レコードを示します (例：Windows 2008 Server)。3 番目のパラメーターは、パターンをトリガーするために新しい discovery_classifier_probe レコードを作成する必要がある場合に使用するパターンを示します (例：Windows OS - Servers)。 更新する必要がある別の分類子レコードがある場合、またはパターンの名前が異なる場合、この関数呼び出しを変更して適切な値を渡すことができます。 例えば、上記の例で、Windows 2008 Server ではなく、Windows 2008 Custom を使用する必要がある場合は、次のように変更できます。 migrate.enablePattern('windows', 'Windows 2008 Custom', 'Windows OS - Servers'); または、使用されているパターンも異なる場合は、次のように変更することもできます。 migrate.enablePattern('windows', 'Windows 2008 Custom', 'Windows OS - Custom'); これは、カスタマイズされた分類子やパターンを使用していて、OOB の分類子やパターンを使用していない、または使用しなくなった場合にのみ行う必要があります。 4) この変更によって影響を受けるシステムプロパティはありますか？ これらの移行スクリプトが実行されると、glide.discovery.ip_based.active というシステムプロパティの値が false に設定されます。 このプロパティは、主にディスカバリーがプローブではなくパターンを使用するようになったことを示すものです。 5) 移行プロセス中にエラーが発生した場合はどうすればよいですか？どのようなログを収集する必要がありますか？ 移行スクリプトを実行すると、このプロセス中に起こっていることのほとんどが syslog テーブルに詳細に記録され、DiscoveryMigrateToPatterns のソース値になります。 以下のスクリーンショットの例を参照してください。 Orlando 以降では、このログ情報も保存される新しいログテーブル (probe_to_pattern_log) も用意されています。詳細については KB0781470 を参照してください。 他の一般的なノードログの調査と合わせて、これらのログの詳細を調査することにより、いつ、どこで問題が発生したかを確認することができます。 さらに支援が必要な場合は、テクニカルサポートでケースをオープンして、調査してもらうこともできます。