本文へ移動する

メインメニューへ移動する

サブメニューへ移動する

事例紹介

Slimによるネットワークトラブル回避

ネットワーク機器のバグにより発生していたトラブルにSlimを導入し、トラブルの回避を実現した事例です。

ネットワーク機器のバグにより発生していたトラブルにSlimを導入し、トラブルの回避を行いました。ネットワーク機器のソフトウェアバグの改修には非常に時間が掛かる事が多いのですが、Slimの様な外部からの監視機器を使用して、とりあえずのトラブル回避やトラブル被害を抑える事が可能となります。

課題

機器のバグにより冗長化経路の切り替えが出来なくなったトラブルの回避

某ユーザ様先でシャーシ型のL3 Switchを使用した冗長構成(CPUモジュールについても2重化)をしていましたが、L3Switchのバグにより、ポートNo.の前半と後半との通信が出来なくなる現象が発生し、スイッチソフトウェア修正までの間、問題が発生しても、通信に大きな影響を与えない様にしたいとの依頼がありました。

図1 改善前の構成図

技術概要

Slimに標準機能とカスタマイズしたシェルの組み合わせにより、問題点を解決

下図の様な構成および処理により、今回のトラブルの回避を行いました。
(以下の処理は、Switch Aで障害が発生した場合のSlim Aの処理に関して説明致します。)

Slim標準機能の処理

  1. Eth0を使用し、CPUのステータスをチェック
  2. (1)のステータスがエラーの場合、カスタマイズしたシェルを実行
  3. (1)のステータスエラーが発生した事をメールにて通知
  4. Eth1を使用し、CPUのステータスをチェック
  5. (4)のステータスがエラーの場合、カスタマイズしたシェルを実行
  6. (4)のステータスエラーが発生した事をメールにて通知

カスタマイズしたシェルの処理

  1. Slim Bやその他のステータスをチェック
  2. (7)がエラーと判断した場合、その他のSwitchに接続しているSwitch Aのポートを全てLink Downさせる

その他の処理

  1. CPUのコンソールポートより、出力されたメッセージをSlimが取得し、その内容をメールにて通知
    → 殆どのSwitchのコンソールポートには、ログでは出力出来ないメッセージやCPUのパニックログ等が出力されます。
図2 改善後の構成図

技術担当者の声

被害を最小限に

通常機器メーカーのソフトウェア修正は、四半期に1度程度で行われ、数多くの問題に対してプライオリティー付けを行い、順次対応されるのが普通です。よって、完全な対応が行われるには時間が掛かる場合があります。ですが、この間にも障害が発生する可能性があり、障害が発生すれば、少なからず損失が発生します。
これを今回の様にSlimを使用し、障害を最小限に抑える事が出来れば、損失も最小限抑えられお客様に喜んで頂けると思っています。
尚、今回の対応に必要とした期間は、テストを含め3日程度でした。

↑ページの先頭へ