Summary

  • WLCG/OSGの測定網は170超の拠点で1日約400万回テストし、各区間の経路変化を遅延・損失・スループットと照合する。
  • 海底ケーブル障害では迂回路の遅延が半分になった一方、スループットは崩れた。4つの分類が経路変化と実害を切り分ける。

tracerouteは経路の絵はがきだ。テストした瞬間にパケットがどこを通ったかは教えてくれる。経路が変われば注目する価値はある。だが、それだけで性能障害の診断書にはならない。ケーブルが切れ、トラフィックが別の道を通っても、アプリケーションの転送は順調かもしれない。逆に、新しい道が速そうに見えて転送が止まりかけることもある。地図とサービスは一緒に読む必要がある。

10月26日のRIPE 93で、Petya Vasilevaは研究・教育ネットワークのための方法を発表した。WLCG/OSGのperfSONAR測定網は170超の拠点を結び、1日約400万回のテストを行う。この手法は送信元と宛先の各区間について最近の経路を基準にし、経路が変わると遅延、パケット損失、スループットの測定と並べて見る。

それぞれの測定は別の問いに答える。tracerouteは観測した経路を示す。OWAMPは片方向の遅延と損失を追える。pScheduler経由のiperf3はスループットを測る。perfSONARの公式文書がテストを分けているのには理由がある。経路が変わってもサービスに影響しない場合があり、性能値が動いても経路スナップショットだけでは説明できない。

ツールは各区間を4つの運用向け分類に分ける。影響確認、経路変更はあるが測定上の影響なし、テスト中断、要確認。NOCは優先順位のついた調査リストを得る。変わった経路をすべて先頭に並べて、グラフが点滅した理由を誰かに説明させる仕組みではない。

ケーブル障害の例が見出しの落ちだ。緊急迂回路で遅延は半分になった。スループットは崩壊した。遅延しか見ないダッシュボードなら、大容量転送が息切れする横で「改善」と報告しただろう。経路は速くなった。仕事は進まなかった。この手法は経路変化を性能記録と並べて、その食い違いを拾った。

別の例では、何カ月も続いた断続的な小さな損失を追った。共有経路の証拠から、問題は一つの拠点の入口装置に絞られた。派手な全断アラームではないが、「時々遅い」を現場で調べられる場所に落とし込める。RIPE NCCの会議報告は、英国の区間、AMS–LON海底ケーブルを含む経路で損失が見られたと記し、NOCとNRENに事故記録の共有を呼びかけた。記録があれば、測定の模様と現場で起きた出来事をつなげられる。

この手法は既存のperfSONAR測定を使う。RIPEによれば、BGPフィードも追加プローブもラベル付き学習データも要らない。診断はすでに区間を見ている測定器のそばに置かれる。ESnetのScience DMZガイドも、遅延・損失を継続確認し、スループットを定期測定してから、技術者がルーティングやスイッチングを調べる流れを説明する。

4分類は赤い点より役に立つ。証拠が何を言えるかを示すからだ。「経路が変わった」は観測。「影響確認」は測定を合わせた判断。「テスト中断」は測る側が視界を失った状態。「要確認」は判断が済んだふりをせず、調査対象を残す。分類ごとに次の質問がある。大音量のアラームだけでは、次の作業にならない。

最後に判断するのは稼働中のネットワークだ。経路が変わってもサービスに響かないことがある。遅延が下がっても転送が崩れることがある。損失が続いても区間全体ではなく入口に原因があるかもしれない。経路、遅延、損失、スループットを同じ時間軸に置けば、NOCは派手なグラフではなく利用者が感じる障害を追える。公開記録に分類ごとの誤警報率はない。その表があれば「影響確認」をどれほど信頼できるかが見える。

Sources: RIPE 93の講演と概要；RIPE NCCの10月26日会議報告；ESnetのScience DMZ測定ガイド；perfSONARテスト文書。