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

したがって、問題を遅らせることなく、前の投稿の 2番目の部分を公開します。 この出版に感謝します-興味のある記事とトピックが続きを見つけたのは素晴らしいことです。

最後の部分で、VCデバイスの1つを再起動した後、正しく動作しなかったという事実に落ち着いたことを思い出させてください。 コメントの1つで正しく指摘されたように、結局のところ、私は家に帰ったことがわかります。 いいえ、最初の部分は私のほぼ5時間の物語の約20分について説明しています。 固定？ 行こう！

リブート後、何が起こったのか、また何が起こったのかは明確ではありませんが、最も重要なのは、クライアントのトラフィックがなくなったことです。 専用の管理イーサネットインターフェイスを介して接続しますが、最初の驚きは、member1がメインREになったことです。

login as: user
user@switch password:
--- JUNOS 12.3R12.4 built 2016-01-20 04:27:51 UTC
{master:1}
user@switch>

原則として、これは起こりますが、怖くはありません。事前にプロビジョニングされたVC構成を備えた同じデバイスを使用しており、いずれもウィザードにすることができます。 OSが更新されており、これは問題ありません。 しかし、これはもはや良くありません：

user@switch> show chassis routing-engine
Routing Engine status:
Slot 1:
Current state Master
DRAM 1024
Memory utilization 45 percent
CPU utilization:
User 14 percent
Background 0 percent
Kernel 11 percent
Interrupt 1 percent
Idle 74 percent
Model EX4500-40F
Serial ID
Start time 2016-06-02 01:28:45
Uptime 34 minutes, 55 seconds
Last reboot reason Router rebooted after a normal shutdown.
Load averages: 1 minute 5 minute 15 minute
0.59 0.80 0.66
{master:1}
user@switch>

デバイスはREを1つしか認識せず、2つあるはずです。 さらに調査しても、不燃性のLEDには理由がないわけではないことが確認されています。

user@switch> show virtual-chassis
Preprovisioned Virtual Chassis
Virtual Chassis ID:
Virtual Chassis Mode: Enabled
Mstr Mixed Neighbor List
Member ID Status Serial No Model prio Role Mode ID Interface
0 (FPC 0) Inactive ex4500-40f 129 Linecard N 1 vcp-1
1 vcp-0
1 (FPC 1) Prsnt ex4500-40f 129 Master* N 0 vcp-1
0 vcp-0
{master:1}
user@switch>

最初のデバイスであるmember0はラインカードとして認識され、ステータスが非アクティブになっています-これは、仮想シャーシでアクティブな役割を果たさないことを意味します。 専用スタックインターフェイス（vcp-1およびvcp-0）がアクティブなので、ローカル接続を試すことができます。


ここにある！ OSは2番目のデバイスと1番目のデバイス（ファームウェアファイルFPC0およびFPC1のバージョンに注意してください）でのみ更新されたため、VCロジックはそれを無効にしました。 何らかの方法で、デバイスがそこにあり、あなたは再びそれを更新しようとすることができます。 1つの問題-更新するとき、Juniperのガイドに従ってそれぞれイメージを/ var / tmpに配置しましたが、ここで空になり、イメージを再度入力する必要があります。 私はこのスイッチに焦点を合わせて、システムの更新/再起動を数回だけ試みます（member1は引き続き動作します）：

{master:1}
user@switch> request system software add /var/tmp/jinstall-XXX.tgz validate member 0
user@switch> request system reboot member 0

ダウンロード/更新プロセスの最後に、私が見るたびに：

Installing disk0s3d:/jinstall-ex-4500-12.3R12.4-domestic-signed.tgz
Verified jinstall-ex-4500-12.3R12.4-domestic.tgz signed by PackageProduction_12_ 3_0
mode = 040700, inum = 38, fs = /instrootmnt/var
panic: ffs_valloc: dup alloc
###Entering boot mastership relinquish phase
KDB: enter: panic
###Entering boot mastership relinquish phase
[thread pid 316 tid 100041 ]
Stopped at kdb_enter+0x1a0: addis r3, r0, -0x7fa4
db>

JunOSのベースとなっているUnixの知識が不足しているにもかかわらず、「KDB：enter：panic」という行は期待できません。 とりわけ、システムはシステムデバッグモード（db>）に陥り、これは非常に悪いです。 参考：ジュニパーには、すべての人にとって使い慣れたコンソールのモードがあり、動作中のハードウェアが構成されており、Unixコマンドラインにrootなどとしてアクセスできます。 rommon> Ciscoにほぼ対応する、オペレーティングシステムイメージを復元および入力するためのloader>ブートローダーモードがあります。 デバッグモードdb>があります。これは、構造の物理コンポーネントに問題がある場合に表示されます。 ジュニパーのTACエンジニアでない場合、このモードではほとんど実行できません。 その瞬間、私はそれが何であるか本当に理解していません、そして誇りに思うWindowsユーザーとして、「次へ」をクリックしようとします：

db> help
DDB Quick Help
-------------------
Type 'c' to continue, 'reset' or 'panic' to restart.

print p examine x search set write
w delete d break dwatch watch dhwatch
hwatch step s continue c until next
match trace alltrace where bt call show
ps gdb reset kill watchdog thread panic
ddbdumpsys dumpsys halt reboot
db> c
Uptime: 2m41s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...

... ...

***** FILE SYSTEM MARKED CLEAN *****
switch (ttyu0)
login: user
Logging to master
...
Connection to master failed, enabling local login
Password:
--- JUNOS 11.1R3.5 built 2011-06-25 01:18:46 UTC
{linecard:0}
user@switch>

奇跡-古いバージョンではありますが、システムが起動します。 当時、更新されたバージョンはメインパーティションに書き込まれ、私の場合はバックアップパーティションからロードできなかったため、この古いバージョンがバックアップパーティション （スライス代替）からロードされたことに気付きませんでした。 したがって、可能な場合はブートローダーを更新することが非常に重要です。これは、問題が発生した場合の別の節約方法です。 注釈として：「マスターへのロギング...マスターへの接続に失敗しました」という行にも注意してください。 VCで結合されたすべてのデバイスには単一の管理コンソールがあります。つまり、たとえばSSH経由で接続すると、すぐにマスターデバイスコンソールに到達します。 私の場合、VCは動作しないため、ローカルハードウェア制御モードになります。

その過程で、OSイメージを実行可能なREにアップロードし、VCメンバー間でコピーします。これはより高速で、WinSCPに気を取られる必要はありません。 デバイス間の通信チャネルがアクティブであるため、これは私の場合でも機能します。

user@switch> file copy fpc1:/var/tmp/jinstall-XXX.tgz fpc0:/var/tmp/jinstall-XXX.tgz

それにもかかわらず、毎回更新して再起動しようとすると同じ結果が得られます。システムデバッグモードで、古いバージョンをダウンロードする機会があります。 したがって、問題は一定であり、ステップを繰り返しても何も達成できません。 その後、私は行くというアイデアを思い付きました-結局のところ、私は稼働中のシステム（member1）を備えたデバイスを持っています、そしてあなたはスナップショットをロールアップしてそこから起動できるUSBフラッシュドライブがあります。 だから私は：

{master:1}
umass1: SanDisk Corporation U3 Cruzer Micro, rev 2.00/0.10, addr 4
da1 at umass-sim1 bus 1 target 0 lun 0
da1 : <SanDisk U3 Cruzer Micro 2.15> Removable Direct Access SCSI-2 device
da1: 40.000MB/s transfers
da1: 973MB (1994385 512 byte sectors: 64H 32S/T 973C)
user@switch> request system snapshot local partition media external
user@switch> show system snapshot media external
fpc0:
--------------------------------------------------------------------------
error: external media missing or invalid

fpc1:
--------------------------------------------------------------------------
Information for snapshot on external ( /dev/da1s1a ) (backup)
Creation date: Jun 2 02:28:20 2016
JUNOS version on snapshot:
jbase : 11.1R3.5
jkernel-ex: 11.1R3.5
jcrypto-ex: 11.1R3.5
jdocs-ex: 11.1R3.5
jswitch-ex: 11.1R3.5
jpfe-ex45x: 11.1R3.5
jroute-ex: 11.1R3.5
jweb-ex: 11.1R3.5
Information for snapshot on external ( /dev/da1s2a ) (primary)
Creation date: Jun 2 02:29:21 2016
JUNOS version on snapshot:
jbase : ex-12.3R12.4
jkernel-ex: 12.3R12.4
jcrypto-ex: 12.3R12.4
jdocs-ex: 12.3R12.4
jswitch-ex: 12.3R12.4
jpfe-ex45x: 12.3R12.4
jroute-ex: 12.3R12.4
jweb-ex: 12.3R12.4
fips-mode-powerpc: 12.3R12.4

フラッシュドライブを接続するときは、メッセージに注意してください。これはシステムデバイスda1として定義されており、将来必要になります。 外部フラッシュドライブのスナップショットは、デバイスの内部ストレージ（メインパーティションのバージョン12.3（/ dev / da1s2a）および11.1-バックアップ（/ dev / da1s1a））のスナップショットを繰り返します。 特定のセクションからシステムを起動する場合にも、スライス名が役立ちます。 問題のあるデバイスにUSBフラッシュドライブを挿入して続行します。

user@switch> request session member 0
--- JUNOS 11.1R3.5 built 2011-06-25 01:18:46 UTC
{linecard:0}
user@switch> request system reboot member 0 media external
Reboot the system ? [yes,no] (no) yes


ここでも、念のため、ローカルデバイス制御セッションに入りました。おそらく、ウィザードコンソールからmember0をリロードすることができました。 再起動すると、常に周期的なシーケンスが表示されます。

U-Boot 1.1.6 (Mar 26 2011 - 04:34:19)
Board: EX4500-40F 10.4
EPLD: Version 6.2 (0x81)
DRAM: Initializing (1024 MB)
FLASH: 8 MB
Firmware Version: 01.00.00
USB: scanning bus for devices... 3 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
ELF file is 32 bit
Consoles: U-Boot console
FreeBSD/PowerPC U-Boot bootstrap loader, Revision 2.4
(hmerge@svl-junos-pool130.juniper.net, Sat Mar 26 02:46:28 PDT 2011)
Memory: 1024MB
bootsequencing is enabled
bootsuccess is not set
new boot device = disk2
can't load '/kernel'
can't load '/kernel.old'
Press Enter to stop auto bootsequencing and to enter loader prompt.
Watchdog timed out. Resetting the board.

スイッチは、これらの繰り返される行よりも先に移動しません。 何だ！？ コアが見つかりませんか？ しばらくして、最後から2番目の行に注意を払い、Enterキーを押してローダーに入ります。

loader> ?
Available commands:
bcachestat get disk block cache stats
boot boot a file or loaded kernel
autoboot boot automatically after a delay
help detailed help
? list commands
show show variable(s)
set set a variable
unset unset a variable
echo echo arguments
read read input from the terminal
more show contents of a file
nextboot set next boot device
lsdev list all devices
install install JUNOS
include read commands from a file
ls list files
load load a kernel or module
unload unload all modules
lsmod list loaded modules
export export variables to U-Boot environment
save save U-Boot environment
heap show heap usage

それは少しばかげていますが、それでも周期的な再起動よりも優れています。 ローダーモード自体は、システムを復元するように設計されています。つまり、私は正しい場所にいます。 動作時間が2時間を超えています...システムイメージと更新の場所にさまざまなオプションを試してみました-結果はありません。

loader> install /var/tmp/jinstall-ex-4500-12.3R12.4-domestic-signed.tgz
invalid URL
loader> install --format file:///jinstall-ex-4500-12.3R12.4-domestic-signed.tgz
cannot open package (error 22)
loader> install --format file:///jinstall-ex-4500-12.3R12.4-domestic-signed.tgz
Device NOT ready
Request Sense returned 06 28 00
cannot open package (error 5)


実際、これらの行は機能するはずですが、何らかの理由で機能しません。その時点では、私は何も考えていませんでした。 同じ周期的な再起動と、カーネルの欠如の宣誓が見られます。 継続的な再起動の過程で、別の興味深いことが浮上します。

Firmware Version: 01.00.00
USB: scanning bus for devices... 3 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
ELF file is 32 bit
Consoles: U-Boot console
FreeBSD/PowerPC U-Boot bootstrap loader, Revision 2.4
(hmerge@svl-junos-pool130.juniper.net, Sat Mar 26 02:46:28 PDT 2011)
Memory: 1024MB
bootsequencing is enabled
bootsuccess is not set
new boot device = disk2

その瞬間、私にとってこれは仮定に過ぎませんが、ジュニパーが0のデバイスを意味することを念頭に置いて、「disk2」が存在することは奇妙に思えます。1つのフラッシュドライブがあります。 また、フラッシュドライブを挿入すると、da1として認識されました。 少し戻ると、コンソールから再起動した直後にデバイスが2つのディスクから起動しようとしたことがわかります（外部USBフラッシュドライブを起動デバイスとして指定したとき）が、これまで気づいていませんでした。 ローダーに戻り、ディスク2がなく、フラッシュドライブがゼロデバイスであるという懸念を確認します。

loader> lsdev
disk devices:
disk0 - USB storage device 0
net devices:
net0:
loader> nextboot disk0:
loader> reboot
Resetting...

それだけですか？ はい、どんなに！ システムは再びディスク2からの起動を試みますが、今は正しい軌道に乗っていると感じています。 途中で、フラッシュドライブ（nextboot diskXsY）上の異なるスライスを使用して近くのオプションを並べ替えましたが、結果はありません。 すでにほとんど絶望的で、ブートデバイスをUブートモードから環境変数として設定する必要があるという情報を見つけました。 この4番目のモードの説明方法とそこでできることはわかりませんが、システムがUSBデバイスをポーリングするときに最初にCtrl + Cを押してブートプロセスを中断することでそこに到達できます（USB：デバイスのスキャンバス...）。 最初の行の<>区切り文字にINTERRUPTが含まれていますが、そのためマークアップとフォントが移動するため、区切り文字を削除しました。

=> INTERRUPT
=> setenv loaddev disk1
=> saveenv
Saving Environment to Flash...
. done
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... writing to flash...
done
. done
Protected 1 sectors
=> reset

......

...
Boot media /dev/da1 has dual root support
WARNING: JUNOS versions running on dual partitions are not same
** /dev/da1s1a
FILE SYSTEM CLEAN; SKIPPING CHECKS
clean, 274948 free (84 frags, 34358 blocks, 0.0% fragmentation)
switch (ttyu0)
login: user
Logging to master
...
Connection to master failed, enabling local login
Password:

--- JUNOS 12.3R12.4 built 2016-01-20 04:27:51 UTC
warning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.
warning: Use of interactive commands should be limited to debugging and VC Port operations.
warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.
warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.
warning: Please logout and log into the VC-M to use CLI.
{linecard:1}
user@switch>

WARNING: cli has been replaced by an updated version:
CLI release 12.3R12.4 built by builder on 2016-01-20 03:55:45 UTC
Restart cli using the new version ? [yes,no] (yes)

Restarting cli ...
{master:0}
user@switch>


再起動後に見たものを見てみましょう：

「警告：デュアルパーティションで実行されているJUNOSのバージョンは同じではありません」は、新しいバージョンがデバイスのメインスライスにのみ含まれているため、恐ろしくも予想もされていません。

「マスターへの接続に失敗しました...」および「警告：このシャーシは非マスターの役割で動作しています...」は、VCがメンバー間の通信を復元し、構成を同期するために時間が必要なため、怖いものではありません。

数分待ってから、システム自体がコンソールの再起動を要求し（警告：cliは更新されたバージョンに置き換えられました）、新しいバージョンが正しいREにロードされます。

私たちはチェックします：

user@switch> show chassis routing-engine
Routing Engine status:
Slot 0:
Current state Master
DRAM 1024
Memory utilization 50 percent
CPU utilization:
User 43 percent
Background 0 percent
Kernel 24 percent
Interrupt 1 percent
Idle 32 percent
Model EX4500-40F
Serial ID
Start time 2016-06-02 03:43:20
Uptime 3 minutes, 22 seconds
Last reboot reason Router rebooted after a normal shutdown.
Load averages: 1 minute 5 minute 15 minute
2.40 1.12 0.46
Routing Engine status:
Slot 1:
Current state Backup
DRAM 1024
Memory utilization 44 percent
CPU utilization:
User 40 percent
Background 0 percent
Kernel 30 percent
Interrupt 1 percent
Idle 28 percent
Model EX4500-40F
Serial ID
Start time 2016-06-02 01:28:45
Uptime 2 hours, 17 minutes, 57 seconds
Last reboot reason Router rebooted after a normal shutdown.
Load averages: 1 minute 5 minute 15 minute
0.49 0.46 0.44

{master:0}
user@switch>
show virtual-chassis

Preprovisioned Virtual Chassis
Virtual Chassis ID:
Virtual Chassis Mode: Enabled
Mstr Mixed Neighbor List
Member ID Status Serial No Model prio Role Mode ID Interface
0 (FPC 0) Prsnt ex4500-40f 129 Master* N 1 vcp-1
1 vcp-0
1 (FPC 1) Prsnt ex4500-40f 129 Backup N 0 vcp-1
0 vcp-0

{master:0}

勝利！ 完全かつ無条件！ 私が自分自身に満足していると言うことは、言うまでもなく、ChSVは屋根を通り抜けただけです。 私の仕事は約4時間続いたという事実にもかかわらず、クライアントがそれを感じなかったので、それはそれほど重要ではありませんでした。 私は自分自身に仮想メダルを与えただけでなく、会社のために多くのお金を節約しました。 この4時間で非常に多くの印象を受けたため、すべてをまとめて全体像を理解するのに何日も（そしてビール）かかりました。

これで、メインセクションの内部ストレージにスナップショットを作成し、1、2週間後のバックアップにのみ残ります。 なぜ1週間で-古いバージョンのシステムをバックアップパーティションからダウンロードする方が、デバイス全体でダウングレードするよりもはるかに簡単であるため、新しいバージョンを運用環境で実行すること。

状況を分析します。

Juniper TACによると、アップグレードの問題はプライマリブートパーティションの損傷が原因でした。 これでは何もできず、スイッチは保証期間内に取得する必要があります。 環境変数を設定するときに、問題がファイルシステムの損傷（不適切な再起動など）によって引き起こされ、アップグレードプロセス（保護されていない1セクターのフラッシュの消去....

誰も明示的にポイントせず、システムにない場合、デバイスがdisk2から起動したかったのか-明確ではないが、TACもコメントするのが難しいと感じた。 ログでは、disk2がどこからともなく表示されることさえトレースできます（新しいブートデバイス= disk1s2が新しいブートデバイス= disk2に変更されることに注意してください）。


実際、この問題により、費やされる時間が1時間半長くなりました。 はい、スイッチもカーネルがないことを誓いますが、なぜシステムがdisk2を使用しようとするのか、システムがローダーでそれを認識していないようであれば、それは明らかではありません。 ブートに問題がある場合、デバイスはディスクを循環しようとしますが、システムはdisk2デバイスを認識しなかったと推測できます。 また、同じフラッシュドライブが将来どのようにデバイスを正常にロードしたか、なぜその理由も疑問を提起します。

ここで間違えた可能性があります。

loader> nextboot disk0:
loader> reboot

ローダーを再起動すると設定が失われるためです。 「リブート」ではなく「ブート」を試さなければなりませんでしたが、その後はしませんでした。

システムの新しいバージョンにより、デバイスの負荷が大幅に増加しました。 古いバージョンでは、更新後の1日のプロセッサ負荷は約27〜30％でしたが、更新後は45〜48％でしたが、デバイスのかなり単純な構成もトラフィックの特性も変わりませんでした。 Juniper TACとの数回のリモートセッションの後、理由を確立できませんでした-メモリリークおよび同様の問題に関する推測がありましたが、ありませんでした。 奇妙だが、事実として受け入れられなければならなかった。

注意深い読者は、ローダー（disk0）に表示されるデバイス名と、正常に起動するために使用されるデバイス名（disk1、次に/ dev / da1s1a）が異なることに気付く可能性があります。 それが接続されているもので、私は断言することはありません。 システムの正常なロードの程度に応じて名前が変わると想定できます。 ローダーがロードされました-いくつかのデバイス名を受け取り、db>から連絡します-他にもあります。 CLIからは、通常「外部メディア」および「内部メディア」を介してデバイスを呼び出します。 一般的に、これまでのところ、仮定のみ。

上記の計算とコマンドのほとんどは、更新のかなり前にガイドにまとめました。 その後、問題が発生した場合は定期的に読み直して補足します。 その中にはdb>モードと==> setenvプロシージャのみがありました。 すべてがうまくいかず、何かが正常に機能しなかったと予測するのは明らかです。 しかし正直なところ、このガイドと彼の精神的な慣らしのための時間がなければ、私はあきらめました。 また、それは夜の仕事であり、心の鋭さは減少しました。

バックアップ-彼らは私をあまり助けませんでしたが、彼らの存在は私の良心と魂を落ち着かせました。 最悪の場合、内部ストレージ全体が破損していても、テキスト構成をコンソールにコピーします。 これらの2つのポイントは、すべてを元の状態に戻す方法と次に行うことの分析ではなく、作業に集中することを保証するものです。

重大な欠点のうち、その過程で、ログを単一のファイルに書き込む複数のPuTTYタブを起動しました。 その後、個々のデバイスとタイムスタンプですべてを整理するのは非常に困難でした。SecureCRTを使用するか、別のデバイスで別のウィンドウを実行することをお勧めします。

そして最後に-シーンからの写真。 この投稿がお役に立てば幸いです。 今後のアップデートで頑張ってください！



PSコマンドの出力では、通常のコードにマークアップを使用しました。これは、特定の言語またはBASHのソースコードを背景にしたマークアップよりも悪く見えます。 ただし、マークアップ「コード」を使用すると、太字で選択できます。これは、コマンドの出力の興味深い場所を強調するために重要でした。 誰もが両方を行う方法を共有している場合（背景+太字）、私は感謝し、将来的にそれを使用することを約束します。
更新：ブラウザーとバージョンが異なると、コードのマークアップが異なって表示されることが判明しました。 テキストをより視覚的で読みやすいものにする方法、さらにたばこを吸うのが面倒です。