Berapa lama waktu yang diperlukan switch ethernet gigabit untuk boot?


9

Salah satu kekurangan kritis yang saya temukan dalam meneliti managed-switches, dan satu yang saya punya pengalaman di masa lalu adalah bahwa apa pun dengan "banyak" firmware akan memiliki banyak masalah yang terkait dengan firmware itu.

Kami sedang meneliti switch rackmount gigabit (48 port). Sepertinya untuk 48 port, satu-satunya pilihan kami adalah switch yang dikelola (Dell, Cisco / Linksys, HP, dll). Yang ingin saya ketahui, yang tidak bisa saya ketahui banyak adalah waktu boot untuk berbagai sakelar yang dikelola.

Jika Anda memilikinya, dapatkah Anda menjawabnya dengan nomor model, dan waktu boot dingin dalam hitungan detik. Saya telah membaca secara online bahwa seri SRW Linksys (sekarang Cisco) kadang-kadang membutuhkan waktu hampir 5 menit sebelum mereka sepenuhnya boot, dan itu adalah biaya yang tidak dapat diterima bagi kami.

Saya khususnya ingin tahu tentang waktu booting sakelar terkelola Dell PowerConnect (model 3548 dan 5448), dan ingin mengonfirmasi waktu booting 5 menit pada SRW2048 atau model serupa, dan waktu boot up HP ProCurve apa pun.

Gabungan semua angka-angka itu harus membentuk gambaran keseluruhan yang menarik tentang waktu boot-up pada sakelar yang dikelola.

[UPDATE: Lebih jauh bagi mereka yang berpikir saya bertanya tentang waktu boot-up karena saya cukup konyol untuk berpikir bahwa ada hubungannya dengan kinerja operasional yang sebenarnya, saya telah memperbarui hal di atas, untuk membuatnya lebih jelas bahwa saya tertarik dalam memahami norma-norma jenis perangkat keras ini, tidak dalam membentuk kesan keseluruhan pada kinerja sakelar berdasarkan pada satu kasus tepi waktu booting. Terima kasih atas waktunya.]

[UPDATE2: Saya akan menambahkan jawaban saya sendiri untuk sakelar SRW terkelola yang kami beli kemarin, model Cisco (mantan tautan) ... Apakah ada yang salah dengan tidak menerima JAWABAN Tentang ini? Saya ingin menjaga pertanyaan ini terbuka untuk mengumpulkan poin data yang mungkin berguna bagi orang lain, serta untuk diri saya sendiri. Secara umum, waktu yang paling lama adalah 5 menit, dan yang terpendek adalah 1-2 menit, dengan pengecualian untuk satu HP ProCurve yang disebutkan, yang super cepat. ]


3
Seberapa sering Anda menemukan diri Anda me-reboot switch?
tomjedrz

1
Bisakah Anda mengembangkan alasan mengapa 5 menit untuk mem-boot switch tidak dapat diterima di lingkungan Anda?
James

Booting adalah satu hal - memiliki satu set stack switch pulih dari kegagalan utama adalah ukuran waktu lain yang berpotensi penting.
Helvick

Ketika saya membaca keluhan online, yang kedua setelah kematian setelah enam minggu atau enam hari uptime yang memerlukan reboot, keluhan kedua yang paling umum adalah waktu boot up angka yang biasanya merupakan keluhan utama dari mereka yang meninjau switch yang dikelola. Karena kita harus menganggap yang pertama adalah kesalahan yang harus diperbaiki dengan peningkatan f / w, yang terakhir akan dianggap sebagai "hal yang baru saja Anda jalani". Saya ingin tahu apa yang akan saya hidupi sebelum saya menyerahkan diri untuk hidup dengannya. Angka SRW dari 97 detik di bawah ini berada dalam kisaran yang bisa saya jalani.
Warren P

Saya harap Anda mengumpulkan beberapa data berguna. Daripada hanya mempertanyakan mengapa Anda membutuhkan data ini, saya ingin menunjukkan bahwa Anda dapat menjalankan switch yang lebih maju secara paralel dan membiarkan PVST + atau mekanisme lain memungkinkan switch paralel untuk mengambil alih dari me-reboot switch selama downtime mereka. Ini adalah salah satu cara pusat data besar menangani masalah waktu boot yang lambat.
kmarsh

Jawaban:


2

Ok, inilah titik data lain untuk Anda dari PowerConnect 5324. Yang merupakan beberapa generasi di belakang model yang Anda lihat. Jadi ambillah untuk apa nilainya.

Jadi perintah ping di bawah ini mengirimkan 1 ping per detik untuk Anda dapat melihat dari output di bawah bahwa dibutuhkan 108 detik dari titik turunnya dari reloadperintah ke titik yang mulai dibalas lagi.

PowerConnect 5324 reboot 108 detik

date && ping 192.168.0.2 && date
Thu Apr 15 00:06:45 EDT 2010
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=2.53 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=2.54 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=2.55 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=2.60 ms
64 bytes from 192.168.0.2: icmp_seq=5 ttl=64 time=2.55 ms
64 bytes from 192.168.0.2: icmp_seq=6 ttl=64 time=2.76 ms
64 bytes from 192.168.0.2: icmp_seq=7 ttl=64 time=2.50 ms
64 bytes from 192.168.0.2: icmp_seq=8 ttl=64 time=2.63 ms
64 bytes from 192.168.0.2: icmp_seq=9 ttl=64 time=3.51 ms
....
64 bytes from 192.168.0.2: icmp_seq=117 ttl=64 time=2026 ms
64 bytes from 192.168.0.2: icmp_seq=118 ttl=64 time=1028 ms
64 bytes from 192.168.0.2: icmp_seq=119 ttl=64 time=30.1 ms
64 bytes from 192.168.0.2: icmp_seq=120 ttl=64 time=3.80 ms
^C
--- 192.168.0.2 ping statistics ---
120 packets transmitted, 13 received, +45 errors, 89% packet loss, time 119202ms
rtt min/avg/max/mdev = 2.502/239.520/2026.970/583.213 ms, pipe 4
Thu Apr 15 00:08:45 EDT 2010

Itu menyenangkan untuk diketahui. Jika generasi yang lebih tua berada di bawah 2 menit, pasti menghubungkan kekuatan terbaru juga di bawah 2 menit.
Warren P

14

Saya tidak dapat membayangkan alasan mengapa Anda akan me-reboot switch cukup sering di lingkungan apa pun untuk mengkhawatirkan hal ini. Setiap reboot saklar harus dilakukan di jendela pemeliharaan dan kemudian beberapa menit tidak akan menjadi masalah besar.

Saya tidak yakin bagaimana menurut Anda waktu booting mencerminkan kinerja sakelar. Switch, seperti kebanyakan perangkat yang tertanam, akan memiliki semacam CPU yang kurang bertenaga yang bertanggung jawab untuk proses booting dan mungkin beberapa fungsi seperti menjalankan cli atau antarmuka web. Tetapi hampir semua fungsi jaringan akan ditangani oleh ASIC yang dibuat khusus dan tidak akan melibatkan CPU sama sekali.


1
+1 mulai menulis hal yang sama, lalu terganggu
Zypher

+1 Saya setuju, mengapa beralih waktu boot begitu penting? Setiap / semua downtime yang direncanakan hanya itu, yang direncanakan.
DanBig

Yang tidak direncanakan terjadi setiap saat. Kami mengalami kegagalan saklar di sini minggu lalu. Anda hanya perlu satu hari di mana Anda memiliki banyak masalah saklar, dan Anda harus merutekan ulang seluruh jaringan kantor, dan Anda mulai peduli tentang hal-hal kecil seperti ini. Karena 5 menit PER booting dingin. Dan pada hari ketika Anda memiliki 10 dari mereka, itu menjengkelkan.
Warren P

1
Cukup adil tetapi sudah pengalaman saya bahwa pemadaman karena kegagalan saklar sangat jarang, tetapi itu terjadi. Jika Anda harus me-reboot switch 10 kali dalam sehari maka waktu boot tidak akan mengubah gangguan secara drastis. Hasil akhirnya akan menjadi jaringan naik dan turun yang mengakibatkan hilangnya produktivitas jika kita berbicara pengguna akhir. Apakah Anda lebih suka switch yang membutuhkan 5 menit untuk boot tetapi akan memperbaiki masalah dalam 1 reboot atau switch yang membutuhkan 3 menit untuk boot tetapi mengambil 5 reboot untuk menyelesaikan masalah Anda. Saya hanya mengatakan bahwa waktu boot mungkin bukan kemenangan yang Anda cari.
3dinfluence

1
Setuju dengan semua yang Anda tulis, tetapi -1 karena bukan itu yang diminta OP (jangan khawatir saya memberi Anda +1 pada jawaban Anda yang lain sehingga Anda masih 8 rep di depan!)
Mark Henderson

4

SRW2048 dari awal yang dingin berjalan 1.2.1, 97 detik

tsavo:~ mcd$ date
Mon Apr 12 14:04:48 EDT 2010
tsavo:~ mcd$ ping 192.168.24.70
PING 192.168.24.70 (192.168.24.70): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2

... snipped ...

Request timeout for icmp_seq 85
64 bytes from 192.168.24.70: icmp_seq=86 ttl=64 time=45.284 ms
^C

tsavo:~ mcd$ date
Mon Apr 12 14:06:25 EDT 2010

Terima kasih telah memberikan apa yang saya minta. Banyak orang tidak dapat memahami mengapa mengukur kinerja bahkan penting. Switch yang tidak dikelola kembali online dalam waktu yang sangat singkat. Waktu yang dibutuhkan untuk beralih ke boot adalah sesuatu yang perlu diperhitungkan oleh admin jaringan. Ini mungkin tidak sering terjadi, tetapi ketika Anda memiliki orang-orang bertanya "kapan sistem akan kembali", tidak terduga harus mengatakan "baik server membutuhkan waktu 3 menit untuk boot, tetapi saklar kami membutuhkan waktu 5 menit".
Warren P

+1 untuk benar-benar menjawab pertanyaan, alih-alih mempertanyakan pertanyaan. Walaupun pada awalnya saya memiliki reaksi "mengapa" yang sama, saya tiba-tiba menyadari bahwa ada banyak sistem yang memiliki persyaratan dan hukuman uptime kontraktual.
kmarsh

@kmarsh Jika ada persyaratan uptime seperti SLA maka jaringan perlu dirancang dengan mempertimbangkan hal itu. Itu tidak selalu mungkin di ujung jaringan perusahaan tetapi jika Anda tetap beralih ke 24 port risiko pada mempengaruhi produktivitas dapat diminimalkan. Switch berbasis sasis yang akan Anda temukan di inti sebagian besar jaringan yang lebih besar menangani jenis barang ini dengan cukup baik. Dengan beberapa modul hotswap PSU dan modul pengontrol. Tetapi seperti yang Anda katakan dalam komentar Anda, Anda juga dapat melakukan hal-hal di lapisan jaringan dengan RSTP / PVST, protokol routing dinamis, dan ikatan ethernet.
3dinfluence

1

Saya tidak memiliki waktu yang tepat di tangan, tetapi kami memiliki kedua Cisco (3750) dan switch HP (2524 & 2510G). Yang Cisco memang butuh beberapa menit untuk memulai. HP membutuhkan waktu sekitar 30 detik. Yang HP adalah 24 port, dan menguji setiap port (melakukan sekitar 4 port per detik), sehingga port 48 akan memakan waktu sedikit lebih lama.


Terima kasih. Cisco 3750 adalah seri katalis / ios bukan? Yang awalnya saya tanyakan adalah mantan Linksys yang sekarang berganti nama menjadi "cisco" beralih bisnis kecil dan non-ios non-katalis.
Warren P

Ya, 3750 adalah perangkat berbasis iOS. Saya pikir semua perangkat Catalyst telah dihapus sekarang, tapi saya bukan ahli.
Chris S
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.