設定ガイド：VCS メンテナンスモード

通常、メンテナンス作業を実施する場合、ISSUを除き、必ず、通信断を伴います。
通信断を伴う設定変更作業、OSアップグレード・ダウングレード、ケーブル不良によるケーブル交換、トランシーバ不良によるトランシーバ交換、ポート不良による機器交換。    

メンテナンス作業といえば、日中に業務を止めることができない作業がほとんどで、通常、深夜帯や休日に作業を行うことが要求されるので、運用管理者やオペレータに負荷がかかり、ここでの人件費が大きな課題となっている企業も多くあります。このようなメンテナンス作業を「無停止」で行えるなら。    

障害発生時の復旧を早めたい、システム運用コストを削減したい、システム担当者の負荷を軽減したい、このような運用者の視点からイーサネット・ファブリックは、NetworkOS7.0.0から「無停止」でのメンテナンス作業が可能となる機能を実装いたしました。  

今回は、このメンテナンスモードを詳しく説明します。    

これまでのVCSのメンテナンス作業

  通常、VCS内のOSアップグレード、機器交換などメンテナンス作業が必要な場合は、トラフィックを迂回=片寄せする手法をBest Practiceとしてご案内します。  

例えば、VDX2のメンテナンス作業を実施する場合、VDX2の各ポートを閉塞し、トラフィックを１系(左側=緑)へ片寄せする手順、これが取りうる唯一の手法になります。    

VCS内は1秒未満の瞬断で切替が可能であるものの、VCS外部のEdgeポートの閉塞では対向機器によっては、通常、1秒を超える接続断が生じます。作業自体は煩雑であり、かつ、慎重な対応が求められます。    

NOS7.0.0では、待望のメンテナンス作業用のコマンド、system-mode maintenanceが実装されました。Production Networkでよく採用される、Spine/Leafのトポロジーでこ のメンテナンスモードがどのように動作するかを解説します。

VCS正常稼動中の状態

  まずは、正常な状態のVCSを確認します。

•  “show vcs”コマンドでVCSステータスを確認

• “show fabric route linkinfo”コマンドでVCS内のリンクと各コスト値を確認

メンテナンスモードの実施 (パターン1: Spine VDX2に対して実行)

2系のSpineであるRouting Bridge(RB)2 = VDX2を経由するトラフィックを1系のSpineであるRouting Bridge(RB)1 = VDX1に迂回するメンテナンス作業を実施します。      

メンテナンス作業用のコマンド、system-mode maintenanceをRB2配下で投入します。

メンテナンス・モードを有効にしたRBは、VCSに引き続き参加するので、Principalからアクセスできます。
もちろん、Principal=RB2に対してメンテナンスモードも可能です。

ISLのコストを意図的に増加 (500 -> 4900)させることによって、該当RBを通過するISLが選択されないようにします。
ただし、ネットワーク構成によっては、設定したRBをトラフィックが流れる可能性もあります。以下に、その例を示します。

上記構成では、Host-AとHost-B間の通信は、RB12を通らない代替パスが存在しないため(RB11-RB12間またはRB2-RB12間を通過しなければHost-AとHost-Bの通信は成り立たない)、RB12がメンテナンスモードでもトラフィックは必ずRB12を通過します。

メンテナンスモードの実施 (パターン2: Leaf VDX11に対して実行)

1系のLeafであるRouting Bridge(RB)11 = VDX11を経由するトラフィックを2系のSpineであるRouting Bridge(RB)2 = VDX2に迂回するメンテナンス作業を実施します。

メンテナンス作業用のコマンド、system-mode maintenanceをRB11配下で投入します。

メンテナンスモード実行中のRBで、administratively downになっているポートの変更は可能ですが、Port ChannelやPort Channelのメンバーポートの有効化はできません。

* 本構成の場合は、メンテナンスモード実行済みのRB11のポート16を有効にはできない。    

トラフィック印加の結果

 以下、複数フローを生成した状態で、パターン1(Spine)・パターン2(Leaf)のそれぞれで、メンテナンスモードにした場合の通信断を確認してみましょう。

• L2トラフィック(MACアドレス x100フロー)
• L3トラフィック(IPアドレス x100フロー)
• 1,000pps
• 1,500バイト
• 双方向

試験の結果から、
パターン1: spineのRBをメンテナンスモードにした場合の通信断時間は、0(ゼロ)になります。
パターン2: LeafのRBをメンテナンスモードにした場合の通信断時間も、sub-secondになります。

メンテナンスモードの実装により、本構成で、spineのRBをメンテナンスする場合は、spineを折り返す通信に対して、「無停止」で作業が行えます。     また、vLAG構成をもつleafのRBでも他のメンバーに通知して経路を切り替えるのでRBが突然ダウンすることによるトラフィックロスを最小限にとどめ、よりGracefulなトラフィック迂回が可能になります。     運用者の視点からもEthernet Fabric = VCSは、ますます進化し続けます。