VirtualChassisのEX4500スイッチでのJunOSアップデート-何が問題になる可能性がありますか？ パート1

Habréを検索しても、このトピックをカバーする記事が必要な量で見つかりませんでした。この投稿はここからです。 トライアル記事のボリュームが多すぎるため、2つの部分があります。



私はここにいるので、自己紹介をしましょう。私の名前はユラで、現在はサービスプロバイダーの会社でネットワークエンジニアとして働いています。 シスコネットワーキングアカデミーでの指導の背後にある、彼らのデバイスの下位/中間ラインと過去4年間のかなり緊密な知り合い-ジュニパーデバイス。 長い間、私はこの投稿について自分の考えを集めることができませんでしたが、最終的には、外見上の認識への渇望と同僚を助けたいという欲求が取り上げられました。



はじめに、更新の原理と上記の計算は、ほとんどの（すべてではないにしても）ジュニパーのデバイスに当てはまります。 私の場合、これらはVirtualChassis（仮想シャーシ/ VC）で実行されている2つのEX4500スイッチです。 VirtualChassisテクノロジー自体は、投稿を不適切な次元に膨らませるため、私には考慮されません。 また、このテーマは、 ここでHabréについて以前に検討されました 。 シスコのVSSにリモートで似ていることに注意してください。複数の物理デバイスが、共通のコントロールパネル、構成、プロトコル、テーブルなどを備えた1つの論理デバイスに結合されています。 あまり気にせず、長所/短所、実装、その他の複雑さについて考えます-ここでの比較は参照マークのようなもので、VCとVSSの違い、およびCisco IOSとJunOSの違いが大きくなっています。



私の患者は、前述のVC（つまり、1つの論理デバイス）で結合され、ネットワークのコアに立っている2つの物理スイッチEX4500です。 ネットワークの上に2つの独立したBGPルーターがあり、それぞれが1つのリンクで物理EX4500（仮想シャーシの「メンバー」）に接続され、デフォルトルートを送信して、フルビューテーブルを合計します。 以下のネットワークは、VCをデフォルトゲートウェイとして使用する仮想マシンと物理サーバーを備えたサーバー群です。 JunOS 11.1R3.5の初期バージョン、稼働時間-インストールから約800日。



更新自体とその必要性は、私が会社に登場するずっと前に浮かびました（そのため、非常に古いバージョンです）。もはや重要ではありません。 このバージョンのサポート期間は終わりに近づいていたため、更新を行う必要がありました。 これはサービスプロバイダーのネットワークの中核であるため、その顧客の中には到達不可能な多くの重要なクライアントがいるため、ダウンタイム要件は非常に厳しいものです。 とりわけ、ここには内部トラフィック（バックアップなど）が追加され、カーネルを通過します。 これから先、少し運がなければ、これらの要件を満たせなかったでしょう。 一方、失敗のシェアがなければ、この投稿は存在しません。



そのため、製造元からの情報によると、システムは次の方法で更新できます。

1. 定期的な更新
2. ノンストップソフトウェアアップグレード（NSSU）
3. インサービスソフトウェアアップグレード（ISSU）

最後から開始-ISSU。 その考えは、最初にメインRoutingEngine（RE）でOSが更新され、すべての管理とトラフィックがスタンバイRoutingEngine（RE）で切り替えられるというものです。 次に、エンジンとバックアップREの更新が切り替えられます。 このためのプロトコルとテーブルは、エンジン間で同期する必要があります-これは、グレースフルルーティングエンジンスイッチオーバー（GRES）およびノンストップブリッジング/ルーティング（NSB / NSR）テクノロジーを使用して実現されます。



このタイプの更新は、デュアル物理RoutingEngine（別名ControlPlane、 ここではアーキテクチャとRoutingEnginsに関する情報を参照）および/またはJunOSが仮想化されているデバイス（たとえば、一部のMXルーターまたはQFX5100およびEX4600スイッチがスタンドでのみ動作する）に適しています-単独モード。 つまり、私の場合、両方のカウントのスパンです。



NSSUは、VCまたはVCF（VirtualChassis Fabric、つまり次世代VC）に統合された1つの物理REを持つデバイスに適しています。 この場合、スタンバイRoutingEngineの役割は、他のデバイスのREによって実行されます。 この手順では、仮想シャーシのシステムを更新し、一度に1つのメンバーデバイスを過負荷にします。これにより、異なるVCメンバーで終端する集約チャネルが使用され、サポートされているVC / VCF構成に適している場合、ダウンタイムを最小限に抑えます。 ここでのGRESとNSB / NSRの存在は、本質的に助言であり、ダウンタイムを削減できます。 素晴らしいように聞こえますが、2つの注意事項があります。JunOS12.1の最小バージョンと、Juniper TACから使用しないことを強く推奨します。 私の場合、システムのターゲットバージョンは12.3で、その時点でメーカーが推奨する最も古いバージョンです。 NSSUとNSB / NSRを有効にします-これにより、シャーシ内のメインREをパケット損失なしでオンザフライで変更でき、ユーザーのダウンタイムなしでシステムを更新できます。



最終的に、私の現実を考えると、唯一の方法が残っています-「通常の」アップデートです。 ここでは通常、すべてのVCデバイスの同時再起動を伴う更新を意味します。それぞれ、約5〜15分間のネットワーク非アクティブ状態です。 推定時間はメーカーのマニュアルから取られますが、私の場合は約4分でした。 このような更新（問題なし）の手順もここで考慮されます 。 読書にうんざりしていて、更新時に起こりうる問題を恐れていない場合は、訪問することをお勧めします。



準備にかなりの時間を費やしたので、すべての計算が私の状況に当てはまるわけではないことを考慮しても、完全な計算を行うことに挑戦しました。 さらに、それらはあなたにとって有用である可能性があります。



まず最初に、製造元（そして今ではすでに私）は、JunOSローダーのバージョンと内部ストレージのレイアウトをチェックして更新することをお勧めします。 私の特定のケースでは、これは必要ではありませんでしたが、後でこれが重要である理由を示します。



デバイスをバージョン10.4R2以前から10.4R3以降にアップグレードする場合、OS自体の更新に加えて、各プラットフォームに固有のブートローダーを更新する必要があります。 ブートローダーを更新すると、内部ストレージが再フォーマットされ、オペレーティングシステムを保存するための2番目のパーティションが作成されます。 その結果、デバイスにはオペレーティングシステムの2つのパーティションがあります。1つはアクティブでもう1つはスペアで、他のファイル（ログ、ホームディレクトリなど）には2つのパーティションがあります。 どのような状況でブートローダーを更新する必要がありますか？ 最初：show chassis firmwareコマンドの出力に、「U-boot」という単語の後、括弧の前のブートローダーバージョンに関する情報が含まれていない場合：

user@switch> show chassis firmware Part Type Version FPC 0 uboot U-Boot (May 19 2010 - 05:03:13) loader FreeBSD/PowerPC U-Boot bootstrap loader 2.2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドとそれに続く多くのコマンドは、個々のVCメンバーデバイスに関する情報を表示することに注意してください。 各デバイスは、FPC番号（デバイスの数に応じて0、1、2など）で識別されます。 この例では、実稼働環境に十分な古いデバイスがなく、ラボからデバイスを1つ取り出したため、1つのデバイスがありました。



2番目：内部ストレージのshow system storageコマンドの出力に3つのパーティション（スライスと呼ばれる）のみが含まれる場合：





ここでは、デバイス/ dev / da0と、dev / da0s1Xとdev / da0s3Xの3つのパーティションのみの存在に注目しています。 dev / da0s2Xはどこに行きましたか？聞かないで-答えが見つかりませんでした。 いずれにしても、ここには4番目のスライスはありません。 存在する場合、 / dev / da0s4dと呼ばれます。



再パーティションが必要であることを確認する別の方法は、 show system storage partitionsコマンドを発行することです。 コマンドがエラーを返す場合、更新が必要です。

ブートローダーを更新し、リポジトリを再パーティションする必要がある場合（疑わしい場合に推奨）、これはフォーマットを意味し、その結果、すべての情報が削除されることを忘れないでください。 したがって、すべての重要な情報を保存する必要がありますが、内部フラッシュドライブの内容全体を保存する必要があります。 ブートローダー自体を更新するプロセスは一般的であり、JunOSの場合も繰り返します。

 user@switch> request system software add /var/tmp/ jloader-XXX.tgz user@switch> request system reboot
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブートローダーとシステムを同時に更新することをお勧めします-これにより、デバイスを一度だけ再起動できます。 1つの例外を除きます。 古いマークアップシステム（3パーティション）を新しいもの（4パーティション）にアップグレードし、同時にJunOSをアップグレードすると、更新されたバージョンが両方のブートパーティション（プライマリおよびバックアップ）に書き込まれます。 これは、更新されたシステムが本番環境でどのように動作するかわからない状況では望ましくない場合があります。 この場合、ブートローダーとシステムを個別に更新し、デバイスを2回再起動する必要があります。 EX4200が1つあるラボでは、ローダーとシステムの更新に13分かかりました。新しいデバイスや高速なデバイスの場合は、それよりも短いかもしれません。



ここでメイントピックに戻ります。



既に述べたように、ブートローダーを更新する必要はなく、すべてのファイルをSFTP、テキスト設定、スナップショットを内部ストレージおよび外部フラッシュドライブに保存することから始めました。

 user@switch> request system snapshot media internal member 0 user@switch> request system snapshot media internal member 0 slice alternate user@switch> request system snapshot media internal member 1 user@switch> request system snapshot media internal member 1 slice alternate user@switch> request system snapshot partition media external
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ジュニパーネットワークスでは認定フラッシュドライブの使用を推奨していますが、容量が2GB以下のほとんどの人はMBRを使用してFATでフォーマットされています。 上記のスクリプトでは、最初の4行で、VCの両方のデバイスのアクティブおよびスタンバイ（スライス代替）セクションで実行中のOSと構成のスナップショットが作成されます。 さらにデバイスがある場合は、「メンバーN」ごとに繰り返します。 メンバーNの代わりに、「 all-members 」キーを使用することもできますが、私は確実性を好みます。 スナップショット自体を使用すると、後でシステムの古いバージョンにロールバックしたり、バックアップパーティションから起動したり、問題が発生した場合に外部フラッシュドライブを使用したりできます。



重要！ スナップショットを作成する前に、システムの現在の実行バージョン（ show version ）およびメインセクションとバックアップセクションの内容（ show system snapshot media internal ）のバージョンコンプライアンスを確認します。 キャッチは、コマンド「システムスナップショットメディアの内部メンバーNを要求する」が現在実行中の（正常な、または実行中の）バージョンをメインパーティションにコピーし、コマンド「システムスナップショットメディアの内部メンバーNスライスを代替する」コマンドがメインパーティションからバックアップにコピーすることです。 私のメインセクションでは、何らかの理由で、バックアップよりも古いバージョンがありました。 オタクと注意は良いだけです。



最後のコマンドは、外部フラッシュドライブにスナップショットを作成し、内部フラッシュドライブの内容とパーティションテーブルに従ってフォーマットします（パーティションキーが必要です）。



アップグレードする前に、外部ドライブ/ FTP / HTTPサーバーからアップグレードしない場合は、システムの新しいバージョンを内部ストレージにコピーすることをお勧めします。 ジュニパーネットワークスでは、システムイメージを/ var / tempに配置することを推奨しています。 アップグレードプロセス中に/ varの内容が削除され、トラブル（私のようなもの）が発生した場合は、イメージを再度アップロードする必要があるため、これを行うことはお勧めしません。 言うまでもなく、システムの重要性を伴うこの遅延は望ましくありません。 ルートでより適切な事前作成ディレクトリを使用し、更新後、「 file delete / directory / filename 」を使用してリポジトリをクリーンアップします。



次に、再起動を伴う実際の更新：

 user@switch> request system software add /var/tmp/jinstall-XXX.tgz validate user@switch> request system reboot
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「検証」キーを使用すると、デバイス構成と新しいバージョンのOSとの互換性を確認できます。 私のEX4500デバイスでは、自動的に実行され、明示的に指定する必要はありませんが、他のデバイスでは設定する必要があります-明らかに優れている、悪化することはありません。



なぜこの長い投稿と警告付きの説明がたくさんあるのですか？ 4分間の再起動と更新の後、インターフェイスLEDは2番目のデバイス（member1）でのみ点灯することがわかります。 すべてのLACPリンクが両方のデバイスに接続され、（幸運、こんにちは！）このデバイスがメインのインターネットチャネルに接続され、クライアントが再びオンラインになったため、私にとってこれはもはや悪くありません。 唯一の非LACPリンクがmember0に接続され、フリートをバックアップサーバーに接続します。 私にとっては、すべてのバックアップが停止されたため、重要ではありません。



この場所で、幸せな管理者が仕事を終え、残りのコーヒーを丸lurみし、静かな心で家に帰り、夜の街で微笑んでいます。 私の場合、引用された資料は記事全体の1/3です。 このトピックがユーザーの興味を引くものである場合、私は楽しみを続けます-それから面白いことだけです！