OpenROADMの論理構成と運用制御 ― APNテストベッドで探る技術と運用手法(その3)

イノベーションセンターの安井です。普段は全社検証網の技術検証、構築、運用を担当しています。

前回OpenROADMに準拠した光伝送網の概要・構築編― APNテストベッドで探る技術と運用手法(その2)にて、OpenROADMアーキテクチャにもとづく分離型 ROADM（Reconfigurable Optical Add/Drop Multiplexer）の物理構成と構築の勘所を紹介しました。今回はその続編として、物理的に構築したROADMノードをソフトウェアからどのように制御・運用しているかを紹介します。

APNテストベッドでは、区間ごとに異なる伝送速度のトランスポンダーを使い分けており、構成によっては複数ベンダーのトランスポンダーが送出した光を同一のROADMに収容する、いわゆるエイリアン波長環境になることもあります。本記事ではこうした環境を前提に、論理的な制御と運用の実践を扱います。

本記事で扱う内容です。

flex-gridによる波長管理の考え方と、異なる伝送速度が混在する環境での運用の工夫（内製Webアプリによる可視化・衝突検出）
内製CLIツールを使ったNETCONFによるROADM制御の実践（設定投入、パワー調整、障害切り分け）
gNMIストリーミング監視の実運用で踏んだ落とし穴と、NETCONFベースのZabbix一元監視に収束した経緯

1. OpenROADMの論理構成の概要
- OpenROADM Device Model
- 制御の全体像
2. flex-grid波長管理
3. NETCONFによるROADM制御
4. 監視・運用ツール連携
5. まとめ

1. OpenROADMの論理構成の概要

IPルーターでは「スロット/ポート」という比較的単純な構造で装置が管理されますが、光伝送装置ではPart 2で見たように物理的な構成がより複雑です。 OpenROADM は、この複雑な物理構成を OpenROADM Device Model としてソフトウェアから操作できる形に整理しています。

OpenROADM Device Model

Part 2では、Degree（方路）やSRG（Shared Risk Group）といった物理的な機能ブロックと、それらを構成するWSS（波長選択スイッチ）、増幅器、OCM（光チャネルモニタ）などの回路パックについて紹介しました。これらの物理構成要素をソフトウェアから操作するために、OpenROADM MSAではYANGと呼ばれるデータモデリング言語で装置の構成や状態を定義しています。

IPルーターであれば、CLIやSNMP MIBで設定や状態にアクセスするのが一般的です。光伝送装置ではこれに相当する仕組みとして、YANGとNETCONFの組み合わせが使われます。 YANGはデータの構造を定義する言語、NETCONFはその構造に基づいて装置と通信するプロトコルです。 OpenROADM MSAはこのYANGモデルを標準化することで、ベンダーが異なっても共通の手順で装置を制御できるようにしています。

OpenROADM Device Modelでは、装置の内部構造を大きく3つのレイヤで表現しています。

レイヤ	内容	具体例
物理層	筐体やカード、ポートの物理構成	Shelf、Circuit-Pack(回路パック)、Port
論理層	ROADMとしての機能ブロック	Degree(方路)、SRG(波長Add/Drop部)
接続層	論理的な光パスの設定	Interface、Roadm-Connection(クロスコネクト)

たとえば、Part 2で紹介したDegree（方路）は、YANGモデル上ではdegreeリストとして定義されており、そのDegreeを構成するWSS、増幅器といった回路パックや外部ファイバの接続ポートが紐づけられています。同様にSRGはshared-risk-groupリストとして、Add/Drop用のポート群を管理しています。

制御の全体像

OpenROADMネットワークの制御は、SDNコントローラーが各ノードに対してNETCONF（ネットワーク機器の設定や状態をXMLベースで操作するプロトコル）を用いたDevice Modelの操作により行われます。

SDNコントローラー
  ↓ NETCONF (port 830)
各ROADMノード (Device Model)
  ├─ 設定: クロスコネクト作成、パワー調整
  └─ 状態取得: 光パワー計測値、アラーム

本記事ではこのうち、ノードレベルでNETCONFによる直接操作に焦点を当てます。コントローラーによるネットワーク全体の自動制御（パス計算や自動プロビジョニング）については範囲外とします。

まず、ROADMノードに設定する波長の割り当て管理について見ていきます。

2. flex-grid波長管理

flex-gridとは

WDM（Wavelength Division Multiplexing：1本の光ファイバに複数の波長の光信号を束ねて伝送する技術）では、各波長にどれだけの周波数帯域を割り当てるかを決める必要があります。

従来のfixed-grid方式では、ITU-T G.694.1勧告に基づき50 GHzまたは100 GHz間隔で波長チャネルが等間隔に配置されていました¹。 100Gの信号も400Gの信号も同じ幅のスロットを占有するため、低速な信号では帯域が余り、高速な信号ではスロットに収まらないという問題がありました。

flex-grid方式では、同じITU-T G.694.1勧告の拡張として、中心周波数を6.25 GHz刻みで配置し、スロット幅を12.5 GHzの整数倍で柔軟に設定できます。信号の伝送速度や変調方式に応じて、必要十分な帯域幅を割り当てられるのが利点です。

項目	fixed-grid	flex-grid
スロット幅	50 GHz or 100 GHz固定	12.5 GHz x N(可変)
中心周波数の刻み	50 GHz or 100 GHz	6.25 GHz
波長配置	等間隔	信号帯域に応じて柔軟
帯域効率	低速信号で無駄が生じやすい	高い
管理の複雑さ	シンプル	スロット割り当て管理が必要

実際にどの程度帯域幅が異なるかを、代表的なプロファイルで整理します。

プロファイル	データレート	ボーレート	占有帯域の概算	実運用でのスロット幅目安
OpenROADM oFEC-31.6Gbd	100G	31.6 Gbaud	約33〜38 GHz	37.5〜50 GHz
OpenROADM oFEC-63.1Gbd	400G	63.1 Gbaud	約66〜76 GHz	75〜87.5 GHz
OIF 400ZR	400G	59.84 Gbaud	75/100 GHz向けを規定(※)	75〜100 GHz
OpenZR+(Rev3.0) 代表	400G	60.14 Gbaud	75 GHz運用が中心	75〜100 GHz
OpenZR+(Rev3.0) 拡張	400G	80.18 Gbaud	100 GHz前提	100 GHz

※ 400ZRは100 GHz DWDM、75 GHz DWDM、単波長無増幅の各アプリケーションを規定しています。

占有帯域の概算にはOpenROADM v9.0で明記されている Bandwidth = Baud rate × (1 + α) を用いています。αはロールオフ係数と呼ばれ、信号スペクトルの裾の広がり具合を示す値で、0.05〜0.2の範囲です。 100Gは37.5 GHz境界に近く、400G（63.1Gbaud）は75 GHz境界に近いため、実運用ではフィルタリングペナルティ（WSSなどの光フィルタを通過する際に生じる信号劣化）や隣接波長干渉を見込んで余裕のあるスロット幅を選ぶのが一般的です。同じ400Gでも、プロファイルによってスロット幅が75 GHzで済む場合と100 GHz必要な場合があります。APNテストベッドでは、機器導入時にプロファイルごとのスロット幅要件を確認し、波長管理ツールのプリセットに反映しています。

flex-gridの波長管理で考慮すること

導入で触れたように、APNテストベッドでは異なる伝送速度やベンダーの機器が混在するエイリアン波長環境を扱っています。こうした環境では、flex-gridの波長管理にいくつかの考慮が必要になります。

まず、前節の表のとおり伝送速度やプロファイルが異なれば占有帯域幅も大きく変わります。同一のトランスポンダーでも伝送モードを変えれば占有帯域幅が変わるため、波長配置では実際の占有帯域幅に応じたスロット幅を個別に割り当てる必要があります。

また、隣接する波長同士の干渉を防ぐために、波長間には一定の未使用帯域（ガードバンド）を確保します。 flex-gridでは12.5 GHz単位のスロット範囲内で自然とガードバンドが生まれる場合もありますが、異なるスペクトル特性を持つ信号が隣接する場合には追加の考慮が必要です。

APNテストベッドでの運用の工夫

flex-gridでの波長管理はfixed-gridと比べて考慮事項が増えます。 APNテストベッドでは、波長の割り当てにあたって管理を単純にするためのルールを設けています。 CDC（Colorless, Directionless, Contentionless）機能により、波長やポートの制約なく任意の方路にAdd/Dropできます。技術的には同一波長を異なる方路で重複使用することも可能ですが、波長リソースに余裕があるため全方路で波長が重複しないよう割り当てています。また、新規波長は基本的に周波数の低い側から詰めていく方針としています。

ただし実際の運用では、PoC（実証実験）対応や経路の異なるパスの追加など、さまざまな要件で波長が追加されます。複数の帯域に分かれて波長が配置されているのが現状です。

APNテストベッドでは機器配置やケーブリングの管理にNetBoxを活用していますが、NetBoxは波長パスの管理を想定した機能を持っていません。 flex-gridのスロット割り当てや衝突チェックは既存のインフラ管理ツールではカバーできず、当初はスプレッドシート等で補っていました。しかし波長数が増えてくると空きスロットの把握や衝突チェックに限界が出てきます。そこで、flex-gridの波長割り当て状況を視覚的に管理するWebアプリケーションを内製して運用しています。

画面上にはCバンドおよびLバンドの全帯域がグラフ表示され、割り当て済みの波長が色付き矩形で並びます。グラフ上をクリックすると中心周波数がフォームに自動入力され、スロット幅は伝送速度に応じたプリセット（37.5/50/75/87.5/100 GHz等）から選ぶ形です。新規波長が既存の波長と周波数帯域で重複する場合は追加前にエラーが出るので、手作業での見落としを防げます。波長ごとにA/Z端のノード名、装置名、インターフェース、中継ノードも記録しており、波長割り当てとパス情報を一箇所で管理しています。

波長の配置が決まったら、ROADMノードに設定として反映します。

3. NETCONFによるROADM制御

OpenROADMにおけるNETCONFの役割

OpenROADM MSAでは管理プロトコルとしてNETCONF（RFC 6241）を採用しており、YANGモデルに基づいてクロスコネクト（波長経路）の設定、増幅器のパワー調整、OCM計測値やアラームの取得といった操作が可能です。

ベンダー提供のコントローラーを使用して管理することもできますが、パワーの確認やちょっとした設定変更といった日常的な作業では、CLIから直接操作する方が手っ取り早い場面も多くあります。一方、コントローラーを介さずにNETCONFで直接操作する場合は、設定変更のたびにXMLファイルを作成・送信する必要があり、この運用は煩雑で難度も高いものでした。

内製CLIツールの紹介

開発の背景

APNテストベッドで採用しているROADM装置はOpenROADM準拠でNETCONFによる設定が可能ですが、手軽に操作できるCLIは用意されていません。そこで、NETCONFの各種操作をコマンドとして抽象化し、対話的に実行できるシェルを開発しました。

アーキテクチャ

制御パスは以下のとおりです。拠点ごとにシェルフコントローラーがNETCONFのエンドポイントとなり、配下のDegree筐体やSRG筐体を制御します。

オペレータ
  └─ 内製CLIツール
       └─ NETCONF (port 830)
            └─ シェルフコントローラー
                 ├─ Degree筐体
                 └─ SRG筐体

操作の概要

コマンド体系はネットワーク機器のCLIに馴染みのある方であれば直感的に操作できるよう設計しています。

set ~ で設定を追加、delete ~ で設定を削除、show ~ でステータス確認
TABでコマンド補完、? でコマンドヘルプ
show configuration でcandidate configを表示、show configuration running でrunning configを表示
candidate configに加えた変更は commit でrunning configに反映
commit discard でcandidate configの変更を破棄

操作例を紹介する前に、OpenROADMのインターフェース階層を整理しておきます。本環境のROADM（MWポート側）では、光チャネルは次の順で構成され、上位インターフェースがsupporting-interface-listで下位を参照します。

OTS (Optical Transport Section)
│     物理ポート/ファイバ区間
└─ OMS (Optical Multiplex Section)
   │     WDM多重信号の層
   └─ MC-TTP (Media Channel Trail Termination Point)
      │     通過可能なスペクトル帯域を定義（min-freq / max-freq）
      └─ NMC-CTP (Network Media Channel Connection Termination Point)
               1チャネル分を定義（frequency / width）

波長の開通時は、NMC-CTPを作成して中心周波数と帯域幅を設定し、そのNMC-CTPをroadm-connectionのsrc-if/dst-ifに指定して光クロスコネクトを作成します（双方向通信では通常2本作成）。以降の操作例に出てくるインターフェース名にはこの階層が反映されています。なお、Add/Drop側のポート種別によっては中間レイヤを省略し、NMC-CTPがポート直下に置かれる実装もあります。

show pm currentコマンドでは各ポートの光パワー計測値をリアルタイムに確認できます。

>show pm current

interface: DEG-1-3-cp-mw-out-nmc-ctp-tx-191.49375
    opticalPowerOutput, direction=tx
        15min: -5.90 dBm
        24Hour: -5.90 dBm
    wssAtt, direction=tx
        15min: 4.70 dB
        24Hour: 4.70 dB

interface: DEG-1-3-cp-mw-out-nmc-ctp-tx-194.30000
    opticalPowerOutput, direction=tx
        15min: -4.00 dBm
        24Hour: -4.00 dBm
    wssAtt, direction=tx
        15min: 3.30 dB
        24Hour: 3.30 dB
(以下省略)

出力にはインターフェース名に波長の中心周波数（191.49375 THz等）が含まれており、各波長のパワーレベルやWSS減衰量を個別に確認できます。

show interfacesコマンドではNMC-CTPインターフェースの一覧と、各インターフェースに設定されたfrequencyとwidthを確認できます。

>show interfaces

name: DEG-1-3-cp-mw-in-nmc-ctp-rx-191.49375
  type: networkMediaChannelConnectionTerminationPoint
  admin: inService
  oper: inService
  frequency: 191493.75 GHz
  width: 75.00 GHz
(以下省略)

論理設定の構造

このツールで設定する論理構成は、前章で紹介したOpenROADM Device Modelの3レイヤ（物理層・論理層・接続層）に対応しています。上位の設定が下位に依存するため、物理層から順に積み上げていく必要があります。

たとえば新しい方路を追加する場合は、まず物理層としてShelfやCircuit-Packを登録し、次に論理層としてインターフェースを作成してポートを有効化します。波長の開通では、接続層としてクロスコネクトを設定することで経路が確立されます。

設定の順序を誤ると依存関係でエラーになるため、この積み上げの構造を把握しておくことが運用上のポイントです。

パワー調整の実践

ROADMノード内の増幅器やVOA（可変光減衰器）を用いてパワーを調整する作業は、日常的に発生する運用の1つです。

パワー調整が必要になる場面としては、新しい波長を追加したとき、トランスポンダーを交換して出力パワーが変わったとき、ファイバ経路を変更したときなどがあります。内製CLIツールを使った調整の基本的な流れは以下のとおりです。

show pm currentでOCMの計測値を確認し、各波長の現在のパワーレベルを把握する
目標パワーとの差分を確認する
setコマンドでOTSインターフェースのspan-loss値（隣接ノード間のファイバ区間損失の設定値）を変更し、commitで反映する。span-loss-receiveが受信側、span-loss-transmitが送信側にそれぞれ対応し、ROADMはこの値に基づいて増幅器やVOAを自動調整する
再度show pm currentで計測値を確認し、目標値に収束するまで繰り返す

ポイントは、一度に大きくパラメータを変えるのではなく段階的に調整することです。 EDFA²は全波長を同時に増幅するため、ある波長のパワーを変えると他の波長にも影響が及びます。また、OCMの計測値が安定するまでには若干の時間を要するため、変更のたびに値が落ち着くのを待ってから次の調整に進む必要があります。

実例として、ある区間（拠点A～拠点B）のパス開通時に行ったspan-loss調整を紹介します。開通直後、拠点B側のトランスポンダーの受光レベルが-20.76 dBmと低めでした。まずshow pm currentで両端のOTSインターフェースの光パワーを確認します。

# 拠点A
>show pm current

interface: DEG-1-5-cp-mw-out-ots-tx          # 拠点B向け送信
    opticalPowerOutput, direction=tx
        15min: 3.40 dBm
interface: DEG-1-5-cp-mw-in-ots-rx           # 拠点Bから受信
    opticalPowerInput, direction=rx
        15min: -13.60 dBm

# 拠点B
>show pm current

interface: DEG-1-3-cp-mw-out-ots-tx          # 拠点A向け送信
    opticalPowerOutput, direction=tx
        15min: 5.90 dBm
interface: DEG-1-3-cp-mw-in-ots-rx           # 拠点Aから受信
    opticalPowerInput, direction=rx
        15min: -22.70 dBm

ここで着目したのは方向によるパワー差です。span-lossは対向局のOTS送信パワーと自局のOTS受信パワーの差から算出します。拠点A→Bでは送信3.40 dBmに対し受信-22.70 dBm（差は約26 dB）、逆方向の拠点B→Aでは送信5.90 dBmに対し受信-13.60 dBm（差は約19.5 dB）と、方向でずいぶん違います。2芯のファイバなので芯ごとに損失が多少異なることはありえますが、ここまでの差はROADM側のspan-loss設定が実態と合っていない可能性があります。前述のとおりROADMの増幅器はspan-loss設定値に基づいてゲインを自動調整するため、設定値が実際の損失と乖離していると増幅が不適切になります。そこでshow interfacesでOTSインターフェースのspan-loss設定値を確認したところ、拠点A側は20 dBに設定されていたのに対して拠点B側は仮の15 dBのままでした。

まずは拠点A側に合わせて、拠点B側のspan-loss-receiveを20 dBに揃えます。

>set interface DEG-1-3 ots span-loss-receive 20
>commit

commit後、トランスポンダーの受光レベルが-20.76 dBmから-16.86 dBmに改善しました。さらに計測値から再計算した約25 dBへ設定したところ-15.83 dBmまで上がり、OSNR³も26.0 dBから28.2 dBに向上しました。受信側が安定したので、対向の拠点A側でもspan-loss-transmitを同様に合わせて本対応は完了です。

パラメータを少しずつ変えながら計測値の変化を見て収束させていく、地道な作業です。

リモートからの障害切り分け

show pm currentはパワー調整だけでなく、障害の切り分けにも使えます。

別の区間のパス開通準備中に、拠点C側でshow pm currentを確認したところ、OSC（Optical Supervisory Channel：光監視チャネル）の入力パワーが検出されておらず、対向から信号が届いていない状態でした。そこで対向の拠点Dに接続して同じコマンドを実行すると、OTS-TXの送信パワーも出力されていないことがわかりました。

# 拠点C（受信側）— OSC入力に信号なし
>show pm current

port: DEG-1-5-cp-osc-cp-osc-in
    opticalPowerInput, direction=rx
        15min: 0.00 dBm

# 拠点D（送信側）— OTS-TXが出力していない
>show pm current

interface: DEG-1-5-cp-mw-out-ots-tx
    opticalPowerOutput, direction=tx
        15min: 0.00 dBm
    opticalReturnLoss, direction=tx
        15min: 28.00 dB

なお、ここで表示されている0.00 dBmは本来1 mWを意味する値ですが、装置によっては信号未検出時にこの値を返すことがあります。 0.00 dBmがきれいに並んでいる場合は信号が来ていない可能性を考慮すべきです。実際の判断ではアラームの有無や対向ノードのPM値と併せて確認します。

設定は正しく入っていたので物理的な問題と判断し、現地での確認へ進むことにしました。リモートから両端のPM値を見比べるだけで「どちら側の、どのポイントで光が止まっているか」を数分で絞り込めます。拠点が遠方の場合、闇雲に現地へ行く前にこの切り分けができると助かります。

4. 監視・運用ツール連携

トランスポンダーとROADMの監視手法の違い

Part 1 ではトランスポンダーの監視にgNMI + OpenConfigを活用していることを紹介しました。一方、ROADMの監視はNETCONF + OpenROADM YANGモデルが中心となります。

現在の構成を以下の表にまとめます。

項目	トランスポンダー	ROADM(シェルフコントローラー)
管理プロトコル	gNMI + NETCONF(2系統並行)	NETCONF
データモデル	OpenConfig	OpenROADM YANG
gNMI取得方式	Streaming(ON_CHANGE)	-
NETCONF取得方式	ポーリング(get)	ポーリング(get/get-config)
主なメトリクス	光パワー(in/out)、Pre-FEC BER	波長別光パワー(OCM)、アンプゲイン、アラーム
Zabbix連携	ssh.run(port 830) + LLD	ssh.run(port 830) + LLD
アラート通知	Cloud Monitoring + Zabbix → Slack	Zabbix → Slack

両者に共通しているのは、最終的にZabbix上でNETCONF経由の監視に収束した点です。そこに至るまでの経緯を含めて紹介します。

gNMI Streaming Telemetryの実運用

Part 1で紹介したgNMI + OpenConfigによるトランスポンダー監視を、実際にAPNテストベッドに展開しました。構成の概要は以下のとおりです。

トランスポンダー
  └─ gNMI (ON_CHANGE)
       └─ gNMIc (GKE Autopilot上)
            └─ Prometheus
                 ├─ Grafana (光パワー・BERの可視化)
                 └─ Cloud Monitoring → Slack (閾値アラート)

Google Kubernetes Engine（GKE） Autopilot上にgNMIc（gNMIコレクター）をデプロイし、トランスポンダーから値が変化したときだけデータを送信するON_CHANGEモードで光パワーやPre-FEC BERなどのメトリクスをストリーミング収集しています。収集したデータはPrometheus経由でGrafanaダッシュボードによる可視化とCloud Monitoringへ集約し、閾値超過時にSlackへアラート通知しています。

gNMI自体は動作しているのですが、実運用に載せてみると想定外の問題がいくつか出てきました。

gNMIサーバ側の実装差異やコレクター側の構成など複数の要因から一部のトランスポンダーでoptical_channelのメトリクスが取得できない
GKE Autopilot上でgNMIcのPodがScaleDown対象となり、ストリーミング接続の切断を繰り返すループに陥った。 KubernetesのPod QoSクラスの調整で解消したが、マネージドKubernetes環境で常時接続型のワークロードを安定稼働させるにはそれなりのチューニングが必要だった
ON_CHANGEモードでは値に変化のない間データは送信されず、Prometheusの時系列が期限切れで消失する（これについてはgNMIcのexpiration設定で対処）

gNMIによるストリーミング監視はリアルタイム性に優れる一方、End-to-Endで安定稼働させるには装置側・コレクター基盤側の双方で作り込みが必要でした。限られた工数の中で監視基盤の信頼性を優先し、NETCONFによるポーリング監視を並行して構築して2系統による補完運用に移行しています。

ZabbixへのNETCONF統合

ROADMとトランスポンダーの両方を、Zabbix標準機能のみでNETCONF監視する仕組みを構築しました。 NETCONFはSSHのnetconfサブシステム上で動作するプロトコル（RFC 6242）です。Zabbixのssh.runアイテムはSSHサブシステム指定をサポートしており、キーの第6引数にnetconfを渡すと（例: ssh.run["<RPC-XML>",,830,,,netconf]）、ZabbixがSSH接続時に自動でサブシステムをネゴシエートします。アイテムキーの第1引数にNETCONF RPCのXMLを直接記述すれば応答XMLが取得でき、外部スクリプトは不要です。

共通のアーキテクチャは以下のとおりです。

Zabbix Server
  └─ ssh.run (SSHエージェント, port 830, NETCONFモード)
       └─ 対象装置
            ├─ マスターアイテム: NETCONF RPCでXMLレスポンスを一括取得
            ├─ 依存アイテム: XMLから前処理で個別値を抽出
            └─ LLD(ローレベルディスカバリ): 波長・ポートごとにアイテムを動的生成

シェルフコントローラー（ROADM）の監視

シェルフコントローラーは4本のマスターアイテムで監視しています。

マスターアイテム	間隔	取得内容
alarm	1h	OpenROADMアクティブアラーム
info	1d	デバイス情報(シリアル、ソフトウェアバージョン)
opticalpower	15m	光パワー(OTS/OMS/NMC-CTP)
pm raw	15m	Performance Monitoringデータ

PM Raw DataからLLDで波長ごとのアイテムが自動生成されます。 Degree側では方路ごとの波長別input/output power、SRG側ではAdd/Drop側のパワーがそれぞれ監視対象です。波長を追加すると、次回のLLDで新しい波長のアイテムが自動的に作られます。

トリガーはOpenROADMアラームの深刻度（Critical/Major/Warning）をZabbixの深刻度に直接マッピングしています。

トランスポンダーの監視

gNMIのoptical_channel欠損を補完するため、トランスポンダーについてもNETCONF経由の監視をZabbix上に構築しました。

トランスポンダーでは1本のマスターアイテム（openconfig-platform:componentsのoptical-channel subtree filter）でNETCONF RPCを発行し、全ポートの光パワーを一括取得しています。 LLDでLine/Clientポートを動的に発見し、ポートごとにinput_power、output_power、pre_fec_ber、laser_shutdownなどのアイテムを自動生成します。

トランスポンダーにはハードウェアバージョンでポート命名規則の異なるモデルが混在しているものの、NETCONFで取得するXML構造は同一であるため、単一のZabbixテンプレートで両バージョンに対応できています。これはLLDによる動的発見の恩恵です。

一元管理で何が変わったか

シェルフコントローラーとトランスポンダーが同一のZabbix基盤に載ったことで、光伝送機器も既存のサーバーやネットワーク機器と同じ運用フローで監視できるようになりました。

Slackアラートについても、Zabbix（NETCONF経由）とCloud Monitoring（gNMI経由）の2系統の通知を同一チャンネルに集約しており、監視元に関わらずチームが1箇所で状況を確認できる体制としています。

内製ツール群と今後の方向性

ここまで紹介したように、APNテストベッドでは波長管理Webアプリ、内製CLIツール、gNMI+Grafana、Zabbixと、複数のツールを組み合わせて運用しています。

現在はZabbixを監視の中核に据え、gNMIをリアルタイム補完として併用する構成に落ち着きつつあります。波長管理Webアプリで管理している周波数情報は、ZabbixのNMC-CTP別パワー監視と中心周波数で対応づけられます。たとえば特定の波長でパワー低下のアラートが上がった際に、波長管理ツール上でその波長のパス情報（A/Z端ノード、中継ノード）をすぐに確認できるため、影響範囲の特定が容易になります。

5. まとめ

本記事では、OpenROADMにもとづく分離型ROADMの論理構成と運用制御を、APNテストベッドでの実践をもとに紹介しました。 flex-gridでの波長管理、NETCONFによるROADM制御、gNMIの運用課題を経てZabbix一元監視に落ち着くまでの経緯を扱っています。

連載全体では、Part 1でトランスポンダー、Part 2で物理構築、本記事で論理制御と、構築から運用までをひと通りカバーしました。光伝送機器の制御・監視はベンダー固有のツールに頼りがちな領域ですが、オープンなデータモデルとNETCONF/gNMIの組み合わせで、IPネットワークの運用と地続きのやり方が取れることをお伝えできていれば幸いです。

今後は波長管理ツールからNETCONF設定を直接投入する連動や、Zabbixの監視データをもとにした運用判断の省力化に取り組んでいきます。

本稿では業界慣用にならい "fixed-grid" / "flex-grid" と表記しています。ITU-T G.694.1原文での主表記は "fixed grid" / "flexible DWDM grid" です。また、fixed gridは12.5/25/50/100 GHzおよび100 GHzの整数倍を定義していますが、本稿では実運用で主流な50/100 GHzを中心に説明します。↩
Erbium-Doped Fiber Amplifier（エルビウム添加光ファイバ増幅器）。光信号を電気に変換せず光のまま増幅できる。ROADMの主要な増幅器として使用される。↩
Optical Signal-to-Noise Ratio（光信号対雑音比）。光増幅を繰り返すほど蓄積されたASE（自然放出光）雑音が増え、値が低下する。伝送品質の重要指標の1つ。↩