エンジニアブログ Arista:Smart System Upgradeで実現する高可用性

ネットワーク機器のアップグレードは、セキュリティと安定性維持に不可欠ですが、従来は再起動による通信断が課題でした。本記事では、Arista Networksの「Smart System Upgrade(SSU)」を用いて、スタンドアロン環境でもヒットレスアップグレードができる技術について検証しましたので解説します。

柳下 雄飛

入社2年目のネットワークエンジニア
Aristaのプロダクトを担当しています。

1. Smart System Upgradeとは?

概要

Smart System Upgrade(SSU)は、Arista EOSで提供されるアップグレード手法の一つで、シングル構成でもダウンタイムを最小限に抑えられることが特徴です。過去に紹介したMLAG ISSUは冗長構成を前提としていましたが、SSUはホストやサーバがNICを1つしか持たず、MLAGを組めないケースなど、冗長化が困難な環境で特に有効です。

 

MLAG ISSU $ SSU.png

 

MLAG ISSUについては過去の記事をご参照ください。

Arista:MLAG ISSUで実現する高可用性 | STech I Lab | 双日テックイノベーション(STech I)

 

従来のアップグレードとの違い

従来のアップグレードでは、コントロールプレーンとデータプレーンの両方が停止し、通信断が発生していました。SSUではアップグレードプロセスが最適化されたことにより、アップグレード中にコントロールプレーンは一時的にオフラインになりますが、データプレーンは既知の情報を保持してトラフィック転送を維持することができます。ただし、再起動後にデータプレーンの更新が行われるため、1秒未満の通信断が発生する可能性があります。( ネットワーク構成によっては数秒程度になる場合もあります。)

 

従来のアップグレード
アプデ修正版.png
Smart System Upgrade

SSUトラフィック.png

 

注意点

SSUを利用する際には、いくつかの注意点があります。まず、OSPFやBGPなどのL3プロトコルを使用している場合、グレースフルリスタートの設定が必須です。これにより、制御プレーンが再起動しても隣接機器は経路情報を保持し、トラフィックの中断を最小限に抑えることができます。また、SSUはすべてのハードウェアや機能に対応しているわけではありません。非互換性や制限事項が存在するため、事前に対応状況を確認することが重要です。さらに、更新内容によってはSSUではなく、通常の再起動が必要になるケースもあります。

SSUの対応状況や機能ごとの制限は、機種やEOSバージョンによって異なる場合がございます。
詳細な対応範囲や制限事項については、最新のメーカー公式ドキュメントをご確認ください。
(トップページ:Product Documentation Library - Arista / 技術仕様:EOS 4.35.1F - Smart System Upgrade - Arista)



2. 検証構成

SSU-topology.png

・トポロジー
Spine:Arista 7050TX × 2台
Leaf:Arista 7050SX × 2台
Host:Spirent Tester (トラフィック生成・測定用)
 
・トラフィック条件
フロー数:5フロー(双方向)
パケットレート:1,000pps
 
・ネットワーク構成
アンダーレイ:EBGP
オーバーレイ:EVPN-VXLAN
Spirent TesterをLeafに接続し、ホスト間で双方向にトラフィックを送信
各フローを複数リンクに分散させ、Leaf#2アップグレード中のパケット損失を確認

3. 検証手順と結果

検証手順

 

本検証では、Leaf#2に対してSSUによるアップグレードを行いました。
実施手順は以下の通りです。

 

1.状態確認

2.グレースフルリスタートの有効化

3.Smart System Upgrade

4.アップグレード後の確認

 

 

1.状態確認

 

検証前のバージョンは4.34.3Mです。今回は4.34.4Mにバージョンアップを行います。

1_show version_leaf2.png

 

 

"show bgp summary"でLeaf#2の全てのネイバー状態がEstablishであることが確認できます。

2_show bgp summary_leaf#2.png

 

 

"show interface counter"でLeaf#2、Spine#1の全てのリンクにトラフィックが流れていることが確認できます。(Leaf#1、Spine#2も同様)

3_show int counter_leaf#2.png4_show int counter_spine#1.png

 

 

"show reload fast-boot"でSSUを実行することができるか確認します。

BGPグレースフルリスタートの設定が必要であると表示されています。

5_show reload fast-boot_leaf#2 .png

 

サポートしていない機能があれば無効化するなどの対応が必要になります。

 

 

 

2.グレースフルリスタートの有効化

 

Leaf#2にBGPグレースフルリスタートを設定します。
グレースフルリスタートを有効化するとBGPセッションが切断されて再確立されるため、一時的な通信断が発生します。

6_router bgp 65300_leaf#2.png
 

グレースフルリスタートを設定すると、BGPピアがダウンしても、restart timerの間は受信した経路情報を保持します。
これにより、再起動中でも既存の転送パスを維持できるため、トラフィックの中断を最小化できます。

 

 

 

3.Smart System Upgrade

 

コンフィグレーションモードでbootイメージを指定します。

"show boot-config"で EOS64-4.34.4Mが指定されていることが確認できます。

7_boot system flash_leaf#2.png

 

 

"reload fast-boot"コマンドでSmart System Upgradeを実行します。

コントロールプレーンが再起動するため、マネジメントインターフェースがダウンします。

9_reload fast-boot_leaf#2.png

 

 

バージョンアップ中にトラフィック転送が継続されていることが確認できます。

1_vup中.png

 

 

Spine#1で"show bgp summary"を確認すると、Leaf#2のBGPネイバーがダウンしていることが確認できます。

10_show bgp summary_spine#1.png

 

 

Spine#1で"show bgp neighbor"を確認すると、Leaf#2(3.3.3.1)でグレースフルリスタートタイマーが動作していることが確認できます。

11_show bgp_neighbor_spine#1.png

 

 

Spine#1でグレースフルリスタートが有効になっていることでLeaf#2から広報されている経路(3.3.3.3)を保持しています。

14_show ip route_spine#1.png

 

 

"show interface Ethernet2"でSpine#1のLeaf#2向けのインターフェースがアップしていることが確認できます。

12_show int counter_spine#1.png

 

 

"show interface counter"でSpine#1ですべてのリンクにトラフィックが流れていることが確認できます。

13_show int counter_spine#1.png

 

 

 

4.バージョンアップ後の確認

 

 バージョンアップが完了しましたが、トラフィック転送が継続されていることが確認できます。

2_vup後.png

 

 

Leaf#2のバージョンが4.34.4Mにアップグレードされていることが確認できます。

15_show version_leaf#2.png

 

 

そして、約90秒後にデータプレーンの更新が行われ、そのタイミングで1秒未満の通信断を確認しました。

3_vupロス.png

 

 

Smart System Upgradeが完了していることが確認できます。

16_show boot log_leaf#2.png

 

 

Leaf#2のBGPネイバーが全てアップしていて正常であることが確認できます。

17_show bgp summary_leaf#2.png

 

 

Leaf#2のすべてのリンクでトラフィックが流れていることが確認できます。

18_show int counter_leaf#2.png

 

 

 

結果

 

・通常のアップグレード

4_reload-loss.png
 
・SSUでのアップグレード

3_vupロス.png

 

今回の検証では、Spine-Leaf構成でLeaf#2を対象にSmart System Upgrade(SSU)を実施し、Spirentでトラフィックを送信しながら通信断を計測しました。通常のアップグレードでは、コントロールプレーンとデータプレーンが同時に停止するため、約 270秒の通信断 が発生しました。一方、SSUではデータプレーンを維持したままコントロールプレーンを再起動するため、通信断は 約0.5秒(1秒未満) に抑えられました。

4. まとめ

今回の検証では、スタンドアロン環境において、Smart System Upgrade(SSU)を利用することでダウンタイムを1秒未満に抑えられることを確認しました。AristaのSSUは、冗長構成が難しいミッションクリティカルな環境でも、単一機器でサービス継続性を確保できる革新的な技術です。ただし、導入にあたっては運用設計や事前準備が重要です。また、SSUが機能する機種やバージョンには制限がある場合がございますので、適用前には事前検証をされることを推奨いたします。さらに、MLAG ISSUやSSUはCloudVisionと組み合わせることで、より効率的なアップグレード運用が可能になります。こちらはAristaのYoutubeチャンネル(Arista Community Central)でも紹介されております。高可用性を求めるネットワークにおいて、SSUは非常に有力な選択肢となるでしょう。ご興味がある方は弊社までお気軽にお問い合わせ下さい。




  • #AristaNetworks
  • #ネットワーク

おすすめ記事

関連ソリューション・製品

エンジニアブログ

Stech I Labに関するお問い合わせは、
こちらのフォームからご連絡ください。