FCoEとDCBが織りなす「ロスレス」の幻想と現実：ネットワークエンジニアの深淵へ
こんにちは。クラウドインフラの現場で幾多のパケットロスと戦い、深夜のトラブルシューティングでパケットキャプチャを眺めては溜息をついていたSREの筆者です。
今日は、現代のクラウドネイティブな環境からは少し「レガシーで重厚」に見られがちな、しかしデータセンターの骨格を支える極めて重要な技術、FCoE (Fibre Channel over Ethernet) と DCB (Data Center Bridging) について語りましょう。「APIを叩けばストレージが繋がる」のが当たり前の今、なぜわざわざ「ロスレスイーサネット」が必要なのか。その裏側にある泥臭い仕組みを紐解きます。
—
なぜイーサネットは「ロス」を許容するのか
本来、イーサネットは「ベストエフォート」の塊です。スイッチのバッファが溢れれば、パケットは容赦なく捨てられます。TCPを使っていれば再送制御が効きますが、ファイバーチャネル（FC）の世界は違います。FCは、ネットワークが信頼できることを前提に設計された、非常に「潔癖」なプロトコルなんです。
この「潔癖なFC」を「大雑把なイーサネット」の上で動かすために生まれたのがFCoEです。そして、イーサネットを「潔癖」に変えるための規格がDCBです。
DCBが実現する「ロスレス」の正体
DCBは単一の技術ではなく、以下の要素の集合体です。これらが揃って初めて、パケットは脱落することなく対向へ届きます。
1. PFC (Priority-based Flow Control: IEEE 802.1Qbb)
これがFCoEの心臓部です。従来のイーサネットのフロー制御（Pauseフレーム）は、インターフェース全体を止めていました。しかしPFCは、CoS（Class of Service）単位で停止信号を出せます。ストレージトラフィックだけを止め、一般のWeb API通信は流し続けるといった器用な芸当が可能です。
2. ETS (Enhanced Transmission Selection: IEEE 802.1Qaz)
帯域を適切に分割し、FCoE用には最低限これだけの帯域を保証する、といった「帯域の交通整理」を行います。
—
現場で直面する設定の現実
FCoEを運用する際、最も恐ろしいのは「不整合」です。スイッチとサーバー（CNA: Converged Network Adapter）の間で設定がズレていれば、PFCフレームが無視され、ストレージアクセスは即座にI/Oエラーとなります。
例えば、Cisco NexusなどのスイッチでPFCを有効にする設定は以下のようなイメージです。
# クラスマップでFCoEトラフィックを定義
class-map type qos match-any FCOE_TRAFFIC
match cos 3 # FCoEは通常CoS 3を利用する
# ポリシーマップでPFCを有効化
policy-map type queuing FCOE_POLICY
class type queuing FCOE_TRAFFIC
priority # 優先度を割り当て
# インターフェースへの適用（各ポートで一致させるのが鉄則）
interface Ethernet1/1
qos policy input FCOE_POLICY
priority-flow-control mode on # ここが重要：PFCを強制ONにするPythonで見る「ロス」の監視：インフラの健康診断
運用フェーズでは、パケットが捨てられていないかを監視し続ける必要があります。API経由でスイッチの統計情報を取得し、PFCの送受信カウントを確認するスクリプトの一例を載せておきます。
import requests
# スイッチのAPIからPFCカウンタを取得する擬似コード
def check_pfc_drop(switch_ip, interface_id):
url = f"https://{switch_ip}/api/v1/interfaces/{interface_id}/stats"
# 本番環境では証明書検証とAuthを適切に設定してください
response = requests.get(url, verify=True)
stats = response.json()
# PFCによる一時停止フレームの受信数を確認
pfc_rx = stats.get("pfc_rx_frames")
if pfc_rx > 1000:
print(f"警告: インターフェース {interface_id} でPFC受信が多発しています。輻輳の疑いあり。")
return pfc_rx
# 運用上のTips: 定期的にPFCカウンタを監視し、
# 閾値を超えたらSlack等にアラートを飛ばすのが定石です。—
SREとしての教訓：なぜ「ロスレス」を語るのか
今のクラウド環境、特にKubernetes上のマイクロサービスでは、TCP/IPがスタックの主役です。しかし、基盤を支えるストレージネットワークや、超低遅延が求められるHPC（ハイパフォーマンスコンピューティング）の領域では、依然としてDCB/PFCの知識がエンジニアの「武器」になります。
トラブルシューティングの極意：
もし、アプリケーション側で「ストレージ接続が断続的に切れる」という謎の事象に遭遇したら、まずはスイッチの show interface priority-flow-control コマンドを叩いてください。カウンタが回っていれば、それはネットワークが悲鳴を上げている証拠です。
「教科書通りに設定したのに繋がらない」――その時、PFCの優先度設定（CoS値）が物理レイヤーで一致しているか、ジャンボフレームのMTUサイズがエンドツーエンドで合致しているか。この「物理層の泥臭い確認」を厭わない姿勢こそが、真のSREの矜持です。
現代の抽象化されたクラウドの裏側には、今もこうして「ロスを許さない」というエンジニアたちの執念が脈々と流れています。皆さんのインフラが、今日も平和にパケットを運び続けることを願っています。
コメント