Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

ダイヤルインテレメトリについて

ダイヤルイン テレメトリは、コレクターがデバイスへの接続を開始してテレメトリ データを取得するネットワーク監視方法です。コレクターはネットワークデバイスに「ダイヤルイン」し、通常はgRPCなどのプロトコルを使用してデータを要求および受信します。

ダイヤルインモードでは、データコレクターはネットワークデバイスへの接続を開始し、テレメトリデータをサブスクライブします。コレクターとデバイスがセッションを確立します。デバイスは、設定された間隔でコレクターにデータをストリーミングします。このモードは、オペレーターが設定データと運用データの両方に対して統一されたチャネルを必要とする場合に一般的に使用されます。

図1:ダイヤルインテレメトリNetwork communication flow: Collector connects to target device via customer cloud network to gather telemetry data.

Junos Telemetryは、gRPCトランスポートを介したgNMIとジュニパー Juniper Extension Toolkit(JET)ダイヤルイン接続の両方をサポートします。

注:

オンデマンド要求(例えば、データをフェッチするための1回限りの「get」操作など)にダイヤルイン方式でgNMIを使用できます。gNMIダイヤルイン接続の場合は、gNMIサービスを有効にする必要があります。POLL(コレクターがスナップショットをポーリングする)およびONCE(単一スナップショット)サブスクリプションモードがサポートされています。デバイスは通常、Junos Telemetryでストリーミングテレメトリ用のgRPCを開始します。

gRPCサービス

gRPCは、セキュアで信頼性の高いデータトランスポートを提供するオープンソースフレームワークです。一連のリモートプロシージャコール(RPC)インターフェイスを使用して、Junosテレメトリを設定し、gRPCフレームワークを使用してテレメトリデータをストリーミングできます。gRPCリモートプロシージャコールは、センサーのプロビジョニングや、テレメトリデータの購読と受信に使用されます。OpenConfigは、YANGデータモデルをサポートしています。OpenConfigデータモデルは、ユニバーサルキー/値形式のGoogleプロトコルバッファ(.gpb)メッセージとしてデータを生成します。

注:Junos OSリリース18.2R1以降、OpenConfigベースのルーティングエンジン(RE)センサーは、UDPを介してgpb構造化メッセージとしてデータをストリーミングできます。

gRPCを使用してデータをストリーミングする

OpenConfig仕様では、データのストリーミングにはgRPCベースのトランスポートのみがサポートされています。gRPC サーバーは、クライアントを実行している管理システムから gRPC セッションを終了します。RPCコールは、Junos OSセンサーの作成をトリガーし、定期的にデータをストリーミングしたり、特定のイベントを報告したりします。次に、これらのセンサーは、適切なgRPCチャネルを介して更新を転送します。

注:

リリース 18.2R1 以降Junos OS、外部ストリーミングサーバーまたはコレクターが、Junos OSを実行するデバイス上でgRPCを介してデータをエクスポートするようにセンサーをプロビジョニングすると、センサー設定は一時設定データベースの junos-analytics インスタンスにコミットされます。設定は、 show ephemeral-configuration instance junos-analytics 操作コマンドを使用して表示できます。以前のリリースでは、センサーの設定は一時的な設定データベースのデフォルトインスタンスにコミットされます。
注:

以前はテレメトリ更新の一部としてエクスポートされていたジュニパーテレメトリヘッダーが、拡張ヘッダーとしてエクスポートされるようになりました。

  • GnmiJuniperTelemetryHeader.protoを使用して、リリース19.3以前を実行しているデバイスからのアップデートJunos OSデコードします。
  • リリース19.4以降を実行しているデバイスJunos OSGnmiJuniperTelemetryHeaderExtension.protoを使用します。

Junos Telemetryソリューションをサポートするために実装されたRPCのリストと説明については、 表1 を参照してください。

表1:テレメトリRPC

RPC名

説明

telemetrySubscribe

指定されたOpenConfigパスのリストのテレメトリパラメーターとストリームデータを指定します。

getTelemetrySubscriptions

telemetrySubscribeを通じて作成されたサブスクリプションのリストを取得します。

cancelSubscription

telemetrySubscribeを通じて作成されたサブスクリプションの購読を解除します。

gRPCを介してストリーミングされるデータは、プロトコルバッファ(.gpb)メッセージのOpenConfigキーと値のペアでフォーマットされます。このユニバーサル形式では、キーは監視対象デバイスのOpenConfigスキーマ内のシステムリソースのパスに対応する文字列です。値は、インターフェイスカウンターなどのシステムリソースの運用状態を識別する整数または文字列に対応します。

注:

Junos OSリリース18.2R1以降、gRPCを介してストリーミングされるデータは、OpenConfigベースのRE(ルーティングエンジン)センサーのキーと値のペアに加えて、protobufとしてフォーマットできます。これらのセンサーは、パケット転送エンジン(PFE)センサーに追加されます。

ユニバーサルキー/値の形式を次に示します。

次の例は、インターフェイスの一連のカウンターをどのように表現できるかを示しています。

マッピングテーブルは、フィールド名をOpenConfigキー文字列にマッピングします。

OpenConfig を使用して Junos テレメトリを有効にする

OpenConfig for Junos OSは、RPCモデルを指定してJunosテレメトリを有効にします。このパッケージには、必要なYANGモデルも含まれています。

特定のOSおよびリリースのGitHubリポジトリにあるすべての YANGデータモデル を、1つのダウンロードパッケージで見つけることができます。パッケージとリポジトリには、ネイティブ構成、状態、RPC データ モデルと、その OS でサポートされている OpenConfig データ モデルと IETF データ モデルが含まれています。また、ジュニパーネットワークスのダウンロードサイトからYANGデータモデルにアクセスすることもできます。

OpenConfigおよびYANGモデルファイルをダウンロードするには、Webブラウザを開いて https://www.hpe.com/us/en/networking/hpe-juniper-networking.html に移動し、 サポート をクリックして https://support.juniper.net/support/ でジュニパーサポートポータルを開きます。 ダウンロード タブを選択し、製品名を入力フィールドに製品名を入力し、製品の 検索 をクリックし、必要な製品を検索して選択し、ドロップダウンリストから適切なJunos OSとソフトウェアバージョンを選択します。同じページを下にスクロールし、 + ツールセクションを展開し、必要なファイルをダウンロードします。OpenConfigモデル用のJUNOS Telemetry InterfaceデータモデルファイルとYANGファイル用のYANGモジュール。

プログラムインターフェイス OpenConfigTelemetry は、テレメトリgRPCサービスを定義します。 telemetrySubscribe RPCは、以下のサブスクリプションパラメーターを指定します。

  • テレメトリデータをストリーミングするシステムリソースを識別するOpenConfigパス(例:/interfaces/interface/state/counters/

  • データが報告され、コレクターサーバーにストリーミングされる間隔(ミリ秒単位)(例: sample_frequency = 4000

ストリーミングサーバーまたはコレクターは、 telemetrySubscribe RPCを使用して、指定されたパスのデータのインラインサブスクリプションを要求します。その後、デバイスはサブスクリプション要求と同じ接続でテレメトリデータを送り返します。

gRPCサーバーの概要

Junos Telemetryでは、マルチポートサービス設定が可能で、異なるポートでリッスンするように複数のテレメトリサービスセットを設定できます。

Junosテレメトリは柔軟なgRPCサービス設定機能を備えており、それぞれに異なるサービス、リスニングアドレス、ポートを持つ複数のgRPCサーバーを設定することができます。これらの機能により、サービス管理とテレメトリデータ収集を詳細に制御できます。安全な通信を確保するために、サーバーごとにTLS証明書を設定できます。gRPCサーバーを設定するには、「 gRPCサービスの設定」を参照してください。

gNMIサービス

gNMI(gRPC Network Management Interface)は、ネットワークデバイスを設定および監視するgRPCベースのプロトコルです。ネットワーク管理のために OpenConfig によって開発された gNMI を使用すると、ネットワーク運用担当者はデバイス構成データを取得および変更し、ネットワークデバイスからリアルタイムのテレメトリ データを購読できます。データ収集は、テレメトリソリューションの重要なタスクです。gNMIは、テレメトリ更新用のONCE、POLL、STREAMなどのサブスクリプションモードをサポートしています。gNMIはgRPCフレームワークを使用し、プロトコルバッファ(protobuf)などの効率的なデータエンコーディング形式をサポートし、TLSによる安全な通信を保証します。YANGモデルは、設定とテレメトリデータの構造を定義します。

gNMIの主なコンポーネントは次のとおりです。

  • gNMIクライアント:外部システムで実行します。デバイスの設定、設定データの取得、テレメトリストリームへのサブスクライブのためのgNMIリクエストを送信します。

  • gNMIサーバー:ネットワークデバイス上で動作し、テレメトリや設定データへのアクセスを提供します。gNMIサーバーは、そのタイプに基づいてリクエストを処理します。設定管理の変更の場合、gNMIサーバーはデバイス設定を更新し、クライアントに応答を送信します。テレメトリデータ収集リクエストの場合は、gNMIクライアントにデータをストリーミングします。

gNMIは、ネットワークデバイスを制御および監視するために、以下のリモートプロシージャコール(RPC)をサポートしています。

  • Get: この RPC は、設定や運用データなど、ネットワーク デバイスの現在の状態を取得します。

    注:

    gNMI getコマンドの type オプションを使用して、取得するデータタイプを指定します。使用可能なオプションは、 CONFIG、 STATE、 ALLです。有効なタイプオプションは CONFIGです。エンコーディングを使用して、gNMIプロトコルがサポートする値エンコーディング形式を定義します。使用可能なオプションには、 JSON、 BYTES、 PROTO、 ASCII、 JSON_IETFがあります。有効なエンコードオプションは、 JSON_IETF と ASCIIです。有効なオプション以外の設定を選択すると、エラーメッセージが表示されます。

  • 設定: 設定 RPC は、ネットワーク デバイスの設定を変更します。

  • サブスクライブ: この RPC を使用して、ネットワーク デバイスからテレメトリ データをサブスクライブします。以下のサブスクリプションモードがサポートされています。

    • ONCE: 現在の値を 1 回だけ取得します。
    • POLL: ポーリングメッセージを受信するたびに現在の値を送信します。
    • STREAM: 指定された間隔で、または変更が発生したときに、更新を継続的に送信します。

    詳細については、「gNMI サブスクリプション」を参照してください。

  • 機能: この RPC を使用して、サポートされているモデルやエンコーディングなどのデバイスの機能を検出します。

gNMIの起源

Pathメッセージのoriginフィールドは、パスのスキーマを識別します。originフィールドは文字列としてエンコードされます。<origin, path>タプルは、メッセージ内のパスを一意に識別します。

originフィールドは、Pathメッセージのどのコンテキストでも有効です。通常、次のように使用されます。

  • SetRequestを使用して、特定のスキーマがターゲット構成を変更していることを示します。
  • GetRequestを使用して特定のスキーマの内容を取得するか、GetResponseを使用してペイロードに特定の<origin, path>スキーマのデータが含まれていることを示します。
  • SubscribeRequestを使用して特定のスキーマ内のパスをサブスクライブしたり、SubscribeResponseを使用して更新が特定の<origin, path>タプルに対応していることを示すことができます。

メッセージで複数のoriginを使用する場合、メッセージ内のすべてのパスにprefixが適用されるため、prefix内のパスを指定しないでください。prefixを指定する場合は、必要なoriginを含めます。RPCペイロードメッセージに対して、1つのリクエストでprefixフィールドとパスフィールドの両方にoriginを指定しないでください。

原点の特別な値

送信元の値は、gNMIプロトコルに対して帯域外で合意されます。 origin フィールドが指定されていない場合、その値はデフォルトで openconfigにする必要があります。オリジンを明示的に設定されることをお勧めします。

YANGモデルデータの起源の定義

openconfig-extensions:originフィールドを使用して、特定のモジュールがインスタンス化される起点を特定できます。

注:

originはnamespaceとは異なります。YANG名前空間はスキーマツリー内の任意の深さで定義されますが、originはスキーマツリー全体を曖昧さを解消するためにのみ使用されます。つまり、ルートにない要素は、そのルートを構成する YANG スキーマ モジュールに関係なく、そのルート エンティティからそのoriginを継承します。

セット内の原産地の一部仕様

Set RPC が、Path メッセージ内に origin を含む delete、update、または replace フィールドを指定する場合、対応する変更を以下の方法で指定されたオリジンに制限する必要があります。

  • replace操作は、指定されたパスで指定されたoriginの内容のみを置き換える必要があります。SetRequest内で指定されていないオリジンは、その内容を置換しないでください。replace操作でoriginの内容を置き換えるには、SetRequestで明示的に指定する必要があります。
  • delete操作では、指定されたorigin内の指定されたパスのコンテンツのみを削除する必要があります。複数のオリジンからコンテンツを削除するには、クライアントはSetRequestのdelete内で複数のパスを指定する必要があります。

これらのルールは、オリジンが重複しないデータを表す場合に適用されます。場合によっては (CLI や OpenConfig など)、オリジンが同じデータに対して異なる「ビュー」を反映することがあるため、それらの相互作用はより複雑になります。

複数の起源を持つセットのトランザクション性

SetRequestが複数のオリジンを指定する場合 (つまり、パスが異なるオリジンを参照する 2 つ以上の操作が含まれる場合)、影響を受けるすべてのデータ ツリーを 1 つのトランザクションとして扱う必要があります。SetResponseは、すべての操作が成功した場合にのみ成功を示します。いずれかの操作が失敗した場合は、すべてのオリジンの変更をロールバックする必要があり、Set RPC に応答してエラーステータスを返す必要があります。