冗長構成でのIOSアップデート - Catalyst

SUPの冗長構成、又はVSS構成時のCatalystで、IOSをアップデートする手順について説明したページです。

アップデートの準備や基本的なIOSアップデート手順については「基本的なIOSアップデート」をご参照下さい。

又、IOSの種類やアップデートの考え方については「IOSの選択」をご参照下さい。

 シャーシ型のCatalystでは中央処理を受け持つスーパーバイザーエンジンを2つ搭載して冗長化可能です。スーパーバイザーエンジンは略してSUPと呼ばれます。

スーパーバイザーエンジンの冗長化

 2基のSUPはアクティブ、スタンバイで動作し、アクティブ側が故障するとスタンバイ側がアクティブになり、通信を継続させます。これをRPRやNSF/SSO等と呼びます。RPRは古いモードで切り替えは数十秒から数分、NSF/SSOの切り替えは0〜数秒と言われています。

 SUPを冗長化するだけでなく装置全体を冗長化し、仮想的に1台の装置として設定出来る装置もあります。これをVSSと言います。

VSS

 VSSでも2台のSUP間の冗長性はNSF/SSOを利用しており、仕組みは同じです。

 冗長構成でのIOSアップデート時は、SUPが2基あるため、両方にIOSのダウンロードが必要です。

 又、アップデート時に装置全体を再起動しても新しいIOSで起動されますが、ネットワークの停止時間が長くなってしまいます。シャーシ型はコアスイッチとして利用される事も多く、コアスイッチの停止はネットワーク全体の停止に繋がります。ネットワークの停止時間を短くするためには、冗長化の機能を利用して片方ずつSUPを再起動します。

アップデートの準備

 アップデート前の準備手順は以下の通りです。

1.冗長構成の確認

 アクティブ・スタンバイがどのスロット間で構成されているかをshow redundancyコマンドで確認します。

【show redundancyの例】
Switch# show redundancy
Redundant System Information :
------------------------------
       Available system uptime = 1 hours, 11 minutes
<略>

Current Processor Information :
-------------------------------
               Active Location = slot 5
        Current Software state = ACTIVE
<略>

        Configuration register = 0x2102

Peer Processor Information :
----------------------------
              Standby Location = slot 6
        Current Software state = STANDBY HOT
<略>

        Configuration register = 0x2102

 赤字部分はSUPが搭載されているスロットを示します。VSSの場合は論理的なスロット番号が表示されます。又、緑の部分により、どちらのSUPがアクティブであるかが分かります。

 ピンク部分はコンフィギュレーションレジスタです。最後の数字が0、又は1になっている場合は以下のように2以上の数字に変更する必要があります。

【コンフィギュレーションレジスタの変更】
Switch# configure terminal
Switch(config)# config-register 0x2102
Switch(config)# exit
Switch# copy running-config startup-config

 上記のように最後の数字が2以上を設定すればコンフィグで指定したIOSファイルから起動します。0x2101等のように最後の数字が1の場合でIOSファイルが2つあると、最初に見つけたファイルから起動されてしまいます。

2.空き容量の確認

 SUP毎にコンソールがあるため、アクティブ側のコンソールに接続し、ファイルシステムに空きがあるか確認します。

【show disk0:の例】
Switch# show disk0:
出力略
xxxxxxxx bytes total (yyyyy bytes free)
Switch# show slavedisk0:
出力略
xxxxxxxx bytes total (yyyyy bytes free)

 赤字部分はスタンバイ側のSUPのファイルシステムを示し、slot0:であればslaveslot0:等slaveが付きます。SUPの冗長化時だけでなく、VSSの時も同様です。

 緑の文字部分で空き容量が確認出来ます。

3.両方のSUPへのIOSダウンロード

 次に両方のSUPにファイルをダウンロードします。

【冗長化されたSUPへのダウンロード】
Switch# copy ftp://username:password@172.16.1.1/IOSファイル名.bin disk0:
Destination filename [IOSファイル名.bin]?Enter
Accessing ftp://username:password@172.16.1.1/IOSファイル名.bin.
..
Loading /IOSファイル名.bin !!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
以下略

Switch# copy ftp://username:password@172.16.1.1/IOSファイル名.bin slavedisk0:
Destination filename [IOSファイル名.bin]?Enter
Accessing ftp://username:password@172.16.1.1/IOSファイル名.bin.
..
Loading /IOSファイル名.bin !!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
以下略

 disk0とslavedisk0両方にダウンロードしています。緑の部分はファイル名の確認のため、そのままエンターキーを押します。

 上記はFTPによるダウンロード方法ですが、TFTPやRCP等でもダウンロード出来ます。指定方法はコマンド一覧の「copy」をご参照下さい。

 又、FTPサーバーを用意する場合は、基本的なIOSアップデートの「FTPサーバーの準備」をご参照下さい。

boot systemコマンドによるアップデート手順

 boot systemコマンドを使ったアップデート手順は以下の通りです。

1.ブートファイルの指定

 再起動した時に読み込むIOSを指定します。

【IOSブートファイル指定】
Switch# configure terminal
Switch(config)# no boot system flash disk0:古いIOSファイル名.bin
Switch(config)# boot system flash disk0:新しいIOSファイル名.bin
Switch(config)# exit
Switch# copy running-config startup-config

 通常、アクティブ側とスタンバイ側ではコンフィグは同期されているため、上記で両方のSUPにコンフィグが保存されます。

2.スタンバイ側への適用

 次にスタンバイ側を新IOSで起動させます。

【redundancy reloadコマンドによるスタンバイ側への新IOS適用】
Switch# redundancy reload peer

 上記でスタンバイ側のSUPが再起動されます。

redundancy reload peerコマンドによるスタンバイ側への新IOS適用結果

 再起動後はshow redundancyコマンドでアクティブ、スタンバイが構成されている事を確認します。

 この時、2つのSUPは新旧異なるバージョンで動作するため、切り替えが遅いRPRで動作します。

3.SUP切り替えと残りの片方への新IOS適用

 次にSUPのアクティブ、スタンバイを切り替えて、もう片方のSUPを新しいIOSで起動させます。

【redundancyコマンドによるアクティブ・スタンバイ切り替え】
Switch# redundancy force-switchover

 上記でこれまでアクティブだったSUPがスタンバイになると同時に新しいIOSで起動されます。

redundancyコマンドによるアクティブ・スタンバイ切り替え結果

 この時、RPRでの再起動のため数十秒から数分の通信断が発生する可能性があります。

 又、切り替え後はshow redundancyコマンドでアクティブ、スタンバイが構成されている事を確認しますが、アクティブとスタンバイのスロットはこれまでと逆になります。

 redundancyコマンドはアップデート専用コマンドではなく、SUPを再起動したり切り替えたりする時に使いますが、redundancyコマンドを利用する事で、装置全体を再起動するよりアップデート中の通信断を短くする事が可能です。

 アップデート専用のissuコマンドをサポートしている場合、アップデート中でも可能な限り2基のSUPで情報を共有し、通信断を最小限に出来ます。

 VSS時は通信断が発生しますが、2台の装置に跨ったイーサチャネルであるマルチシャーシイーサチャネル、略してMECを構成していれば、通信が途切れる事なくアップデート出来ます。

MEC

 issuコマンドによりアップデートを開始出来るかはshow issu stateコマンドで確認出来ます。

【show issu stateコマンドの例】
Switch# show issu state
Slot = 5
RP State = Active
ISSU State = Init
Boot Variable = bootflash:古いIOSファイル名.bin

Slot = 6
RP State = Standby
ISSU State = Init
Boot Variable = bootflash:古いIOSファイル名.bin

 赤字部分がInitになっている必要があります。Disabledになっている場合はSUPが動作していません。又、既にアップデート途中の場合はLoad Version、Run Version等と表示されます。

 アクティブ、スタンバイ両方にIOSをダウンロードした後の手順は以下の通りです。

1.スタンバイ側への適用

 スタンバイ側を新IOSで起動させます。

【issuコマンドによりスタンバイ側への新IOS適用】
Switch# issu loadversion 5 bootflash:IOSファイル名.bin 6 slavebootflash:IOSファイル名.bin

 上記で6スロット目のSUPが再起動されます。赤字部分はアクティブ側、緑の部分はスタンバイ側のSUPが搭載されたスロットを指定する必要があります。

issuコマンドによるスタンバイ側への新IOS適用結果

 上記はSUPが冗長化された時の図ですがVSSでも同様です。

 この時、2基のSUPは新旧バージョンが異なりますが、可能な限り切り替えが速いNSF/SSOで動作します。

2.アクティブ・スタンバイ切り替え

 次にアクティブ・スタンバイ切り替えです。

【issuコマンドによるアクティブ・スタンバイ切り替え】
Switch# issu runversion 6

 このコマンドで以下のようにアクティブ・スタンバイが切り替わり、新IOSでスイッチは動作するようになります。

issuコマンドによるアクティブ・スタンバイ切り替え結果

 切り替わり後はshow redundancyコマンドでアクティブ、スタンバイが構成されている事を確認しますが、アクティブとスタンバイのスロットはこれまでと逆になります。

3.元アクティブ側への適用

 最後にスタンバイになった元アクティブ側で新IOSを適用します。

【issuコマンドによる元アクティブ側への適用】
Switch# issu commitversion 5

 上記コマンドで元アクティブ側も新IOSで動作するようになります。

issuコマンドによる元アクティブ側への新IOS適用結果

 issu commitversionコマンド実行後はshow issu stateコマンドでステータスがInitになっている事を確認します。issu commitversionコマンドまで完了出来ず、ステータスがInitになっていない場合、デフォルトでは45分でSUPが再起動されて古いIOSに戻ります。

前のページ「基本的なIOSアップデート

サイト関連1

設定編「IOSの選択
  • このエントリーをはてなブックマークに追加