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 Juniper Extension Toolkit(JET)ダイヤルイン接続の両方をサポートしています。

手記：

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

gRPC サービス

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

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

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

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

手記：

Junos OS リリース 18.2R1 以降、外部ストリーミング サーバー(コレクター)が、Junos OS を実行しているデバイスで gRPC を介してデータをエクスポートするようにセンサーをプロビジョニングすると、センサー設定はエフェメラル設定データベースの junos-analytics インスタンスにコミットされます。設定は、 show ephemeral-configuration instance junos-analytics 運用コマンドを使用して表示できます。以前のリリースでは、センサーの構成は、一時的な構成データベースの既定のインスタンスにコミットされます。
手記：

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

  • GnmiJuniperTelemetryHeader.proto を使用して、Junos OS リリース 19.3 以前を実行しているデバイスからの更新プログラムをデコードします。
  • Junos OS リリース 19.4 以降を実行しているデバイスには GnmiJuniperTelemetryHeaderExtension.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 Telemetryを有効にする

Junos OS向けOpenConfigは、Junos Telemetryを有効にするRPCモデルを指定します。このパッケージには、必要な YANG モデルも含まれています。

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

Web ブラウザを使用して、ジュニパーネットワークスの Web ページにあるすべての Junos プラットフォーム ソフトウェアのダウンロード URL に移動します。 https://www.juniper.net/support/downloads/。 [Network Management] タブで、下にスクロールして [OpenConfig] を選択します。「ソフトウェア」タブを選択します。適切なバージョンの OpenConfig モジュールを選択します。

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

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

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

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

gRPC サーバーの概要

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

Junos Telemetry は柔軟な 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です。有効な type オプションは CONFIG です。エンコーディングを使用して、gNMI プロトコルがサポートする値エンコーディング形式を定義します。使用可能なオプションには、 JSON、 BYTES、 PROTO、 ASCII、および JSON_IETFがあります。有効なエンコード オプションは JSON_IETF と ASCII です。有効なオプション以外の設定を選択すると、エラーメッセージが表示されます。

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

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

    • ONCE: 現在の値を一度だけ取得します。
    • 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 に応答してエラー状態を返す必要があります。