- はじめに
- DCI（Data Center Interconnection:データセンター間相互接続)
- IP over DWDM
- 400G-ZR/ZR+
- Transceiverの選定
- 実環境への導入（＆トラブル）
- トラブルシュート
- 振り返り
- 最後に
はじめに
こんにちは、ITインフラ本部インフラ部ネットワークグループ NAD（Network Architecture Design）チームの大城です。
NADチームは高品質かつ効率的なネットワーク設計・構築をすることで、全ユーザーおよび事業サービスに最適な接続環境と将来を見据えたネットワークの安定稼働を目的として活動しています。
現在、ネットワークグループではバックボーンのリプレースに取り組んでおり、本記事ではDCIに400G-ZR/ZR+を導入した事例を紹介したいと思います。
DCI（Data Center Interconnection:データセンター間相互接続)
ネットワークグループが目指しているバックボーンを簡単に図示すると以下のような構成になり、バックボーン拠点は物理的に離れた各データセンターと接続しています。
上記のように複数のデータセンターを利用することは現地で作業等を行うケースでは大変ですが、以下のメリットがあります。
可用性
物理的に異なるデータセンターを利用することにより、データセンターレベルでの障害があった場合でもサービスの継続が可能です。
（「データセンターの障害」というと大規模災害を連想しがちですが、データセンターの電源設備障害も含まれており、こういったケースは過去にも発生しています）
拡張性
利用しているデータセンターに収容できるサーバーが上限に達した場合は、単一のデータセンター利用時と比べて拡張性が高いです。
(クラウドを利用している事業者も多いと思いますが、DMMオンクレのようにクレーン筐体の実機操作が必要とされるような「事業特性上、クラウド利用が難しい」サービスや、「オンプレの方がクラウドより低コスト」なサービスもあるためDMMのネットワークでは拡張性も大事です)
これらの理由からDMMでは複数のデータセンターを利用しており、データセンター間を接続するのが DCI (Data Center Interconnect) になります。
IP over DWDM
前項で説明したとおりデータセンター間を接続するのがDCIですが、最近はDCIで「IP over DWDM」の技術を導入する事例が増えてきました。 まずは、IP over DWDMについてお話する前にWDMについて説明します。
WDMは 「波長分割多重:Wavelength Division Multiplexing」 を意味しますが、1本の光ファイバーで大容量・長距離の通信を実現する仕組みであり以下の機能があります。
- Transponder
NW機器（Transceiver）からの光信号を特定波長の光に変換。 - Mux/Demux
複数の異なる波長の光信号を合波/分波する。 - Amplifier
対向先まで光信号が届くように光を増幅します。
これに対しIP over DWDMでは、以下の図の様にTransponder機能をTransceiverに実装したものになります。
IP over DWDMでは既存のWDMと比べ、Transponder機能がTransceiverに内蔵されているため独立したTransponder製品を自前で用意する必要はなくなります。
また、距離や構成によってはMux/Demux,Amplifierの機器も不要になります。
結果的にコストを抑えることが出来るので、ネットワークチームではバックボーン拠点同士を結ぶDCIに400GのIP over DWDMを導入することにしました。
400G-ZR/ZR+
IP over DWDMに対応した400G Transceiverの規格は、400G-ZR/ZR+になります。
そして、Transponderで用いる光通信技術をコヒーレント通信と表現することもあります。
そのため、IP over DWDMのTransceiverを 「コヒーレントTransceiver」 と呼ぶこともあります。
データセンター内で使われる一般的なTransceiverと比較して、コヒーレントTransceiverを利用する際には以下の点を考慮する必要があります。
波長
一般的なTransceiverでは波長は固定ですが、コヒーレントTransceiverでは波長を設定できます。
その際は、受信側のTransceiverと波長を揃える必要があります。
今回は 「波長貸し」 と呼ばれる回線サービスを利用したため、回線事業者指定の波長に合わせる必要がありました。
送信パワー
一般的なTransceiverでは送信パワーについては固定値ですが、コヒーレントTransceiverは長距離通信をするために対向先まで光信号を届ける必要があります。そのため、送信パワーを環境に合わせて設定する必要があります。
今回は回線サービスの網内にアンプがあるため送信の細かい調整は行わずに済みました。
FEC（前方誤り訂正）
FEC（前方誤り訂正）とは、データ通信において送信時に冗長な符号を付加し、受信側で（再送を要求することなく）伝送路のノイズなどによって発生・破損したデータを自動的に検出・訂正する機能です。
FECはネットワーク機器側で行うため、一般的なTransceiverではFECの機能は搭載されていません。
しかし、コヒーレントTransceiverでは、長距離の光通信を目的としているため信号が劣化することを想定しており、Transceiver内にFECの機能を有しています。
400G-ZR/ZR+では、 CFEC , OFEC と呼ばれるFECがあり、こちらも対向先と揃える必要があります。
消費電力
コヒーレントTransceiverはTransponder機能が内蔵されているため、一般的なTransceiverと比べても消費電力が高いです。
そのため、ネットワーク機器がコヒーレントTransceiverの動作に問題ない電力を供給可能かも確認が必要です。
発熱対策
「消費電力が高い」ということは必然的に発熱も高いということになります。
そのため、コヒーレントTransceiverが安定して動作する（~70℃以下）ためにネットワーク機器の筐体の冷却設定や、利用するポートの制限を考慮する必要があります。
Transceiverの選定
コヒーレントTransceiverの導入を決定した箇所はバックボーン拠点を結ぶDCIになり、該当DCIは複数のサービスの通信が流れる重要な箇所でもあります。
そのため、当初はメーカー純正品も検討していましたが、3rd Party製と比べTransceiver1つにつき価格に大きな開きがありました。
また、今後「他のDCIでコヒーレントTransceiverの導入も検討する機会はあるだろう」という事で、チャレンジする意味でもネットワークチームでは3rd Partyの400G-ZR/ZR+のTransceiverを導入することにしました。
実環境への導入（＆トラブル）
今回導入したDCIでは通信事業者の波長貸しサービスを利用したこともあり、疎通確認もスムーズに進みました。
しかし、特定のDCIにおいてOSNRの運用マージンの値が少ないと判明しました。
OSNR（光信号対雑音比）
OSNRとは、光信号における光のパワーとノイズの比率を示す値です。
光通信では光ファイバー内を「波」という形で進んでいきますが、長距離を進むにつれて位相（周波数）に揺らぎが生じノイズとなります。
また、対向先まで光信号を届けるために、アンプなどで光信号を増幅した場合は上記の揺らぎも同様に増幅してしまうためノイズが増える原因となります。
CFEC/OFECでのOSNRの下限値、到達距離は以下になります。
| OSNR(dB) | 到達距離 | アプリケーション | |
|---|---|---|---|
| CFEC | 26.0dB | 120km | 400G-ZR |
| OFEC | 24.0dB | 600km | 400G-ZR+ |
そして、実環境でのOSNRの値は以下の結果でした。
MIN AVG MAX Operational Configured TCA Operational Configured TCA
Threshold(min) Threshold(min) (min) Threshold(max) Threshold(max) (max)
OSNR[dB] : 26.30 26.45 26.60 0.00 NA NO 40.00 NA NO
上記は、導入当初CFECで設定した際の、OSNR値です。（平均：26.45dB）
当初は、DCIの距離は120kmもないためCFEC（400G-ZR）で十分と考えていましたが、運用マージンが低いためOFEC(400G-ZR+)へ変更することにしました。
しかし、特定ベンダの機器でOFECが動作しないというトラブルに見舞われました。
そのため、いったんはコヒーレントTransceiverや接続する光ファイバーの端面清掃を再度実施したところOSNRも改善しました。
端面清掃後のOSNR値はこちら。
MIN AVG MAX Operational Configured TCA Operational Configured TCA
Threshold(min) Threshold(min) (min) Threshold(max) Threshold(max) (max)
OSNR[dB] : 26.90 27.03 27.30 0.00 NA NO 40.00 NA NO
トラブルシュート
OFECが動作しなかった原因ですが、当初はコヒーレントTransceiverの不良と想定しました。
そのため、切り分けとしてOFECで動作しているコヒーレントTransceiverを該当機器で試したところ同様にOFECで動作しないことが判明しました。
その場合は機器側の異常が考えられます。
機器側のハードウェアの状態に異常もないため我々の設定不備も疑い、コヒーレントTransceiverの収容ポートの変更や対応OS Versionの調査、公式リファレンスとの設定差異を確認しましたが問題ありませんでした。
3rd PartyのコヒーレントTransceiverを利用したためベンダーサポートも受けることができず、打つ手なしかと思われましたがOS VersionUPした別の同機種で試したところ問題のコヒーレントTransceiverがOFECとして動作しました。
OFECで動作しなかった機器のOSは400G-ZR/ZR+対応になったばかりのOS Versionだったので、今回のように3rd Party製のコヒーレントTransceiverではうまく動作しなかったのかもしれません。
振り返り
400G-ZR/ZR+の導入はネットワークチームとしても初めての試みでしたが、現状問題なく動作しています。
WDMに代表される光伝送技術は触れる機会が少ないため、コヒーレントTransceiver（400G-ZR/ZR+）の導入には色々問題があるかと予想していましたが、
設定自体は比較的わかりやすいと感じました。
加えて、DCIとして波長貸しサービスを利用したことで、一部設定（送信パワー）等も調整不要だったことも導入の容易さに繋がったと思います。
ただ、OSのVersionによってFECの設定が反映されない等、導入事例は増えつつあるものの比較的新しい技術とも感じました。
そのため、コヒーレントTransceiverを導入する際は、以下の2点を行なっておくともっと導入がスムーズに進むと思います。
- 波長貸しのような回線サービスを利用する場合は、回線サービス側とパラメータについては一通り認識合わせを行う。
- 波長・送信パワー・FEC等の設定可能項目は一通り試してコヒーレントTransceiverが問題なく動作するか確認する。
今回のケースでは、導入したコヒーレントTransceiverを事前に借りる機会がありました。
しかし、借りる期間の関係上「機器が3rd Party製コヒーレントTransceiverを認識するか？」や「FEC（CFEC）の設定が入るか？」といった確認ぐらいしか行えていませんでした。
この点は反省として今後に活かしたいと考えています。
ネットワークチームではDCIにダークファイバーを調達して利用する機会もあります。
これまでダークファイバーを調達する場合はWDMのような機械の導入が必要でした。
「複数の機器から出る光信号を単一の光ファイバー経由で通信する」という点ではこれまで通りWDMは有用ですが、DCIの構成によってはコヒーレントTransceiverでの構築も可能になります。
また、3rd PartyでのTransceiverで構成できたことで、費用という面でも選択肢に幅が出てきました。
現在、DMMネットワークのトラフィックは増加傾向にあり、コヒーレントTransceiverについても800G-ZRの製品も登場しています。
引き続き、この分野のキャッチアップに努めていきたいと思います。
最後に
DMMでは年々オンプレミスのトラフィックは増えており、今後も増加傾向にあります。
DMMグループの多種多様なサービスを支える、大規模システムインフラのネットワークエンジニアとして活躍しませんか？
NADチームは以下を目標に活動しています。
ユーザーと事業サービスに対して最適な接続性を提供し続ける。
コミュニケーションを通して要件の抜け漏れを防ぎ、高品質なネットワーク設計と効率的な構築を目指す。
資料作成を通して知識の共有や情報の更新などを行い、プロジェクトを属人化させず、安定したネットワークを事業部に提供し続ける。
プロジェクト進行状況の透明性確保、最新技術に基づく次世代ネットワークを探求する。
ご興味のある方は、ぜひカジュアル面談もやっているので気軽にどうぞ！
pitta.me
