Mengapa penguncian server mengetuk server lain dari jaringan?

Kami memiliki beberapa lusin server Proxmox (Proxmox beroperasi pada Debian), dan sekitar sebulan sekali, salah satu dari mereka akan mengalami kepanikan kernel dan terkunci. Bagian terburuk tentang penguncian ini adalah ketika server yang ada di sakelar terpisah dari master kluster, semua server Proxmox lain di sakelar itu akan berhenti merespons hingga kami dapat menemukan server yang benar-benar macet dan reboot.

Ketika kami melaporkan masalah ini di forum Proxmox, kami disarankan untuk meningkatkan ke Proxmox 3.1 dan kami sedang dalam proses melakukan itu selama beberapa bulan terakhir. Sayangnya, salah satu server yang kami migrasi ke Proxmox 3.1 dikunci dengan panik kernel pada hari Jumat, dan sekali lagi semua server Proxmox yang berada di saklar yang sama tidak dapat dijangkau melalui jaringan sampai kami dapat menemukan server yang crash dan reboot.

Yah, hampir semua server Proxmox di sakelar ... Saya merasa menarik bahwa server Proxmox di sakelar yang sama yang masih di Proxmox versi 1.9 tidak terpengaruh.

Berikut ini adalah cuplikan layar konsol server yang mogok:

masukkan deskripsi gambar di sini

Ketika server terkunci, seluruh server pada switch yang sama yang juga menjalankan Proxmox 3.1 menjadi tidak terjangkau dan memuntahkan yang berikut ini:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
...etc...

uname -a output dari server yang terkunci:

Linux ------ 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 x86_64 GNU/Linux

pveversion -v output (disingkat):

proxmox-ve-2.6.32: 3.1-109 (running kernel: 2.6.32-23-pve)
pve-manager: 3.1-3 (running version: 3.1-3/dc0e9b0e)
pve-kernel-2.6.32-23-pve: 2.6.32-109

Dua pertanyaan:

Ada petunjuk apa yang menyebabkan panik kernel (lihat gambar di atas)?
Mengapa server lain pada sakelar dan versi Proxmox yang sama dihilangkan dari jaringan sampai server yang terkunci di-reboot? (Catatan: Ada server lain di sakelar yang sama yang menjalankan Proxmox versi 1.9 yang lebih lama yang tidak terpengaruh. Selain itu, tidak ada server Proxmox lain di gugus 3.1 yang terpengaruh yang tidak berada pada sakelar yang sama.)

Terima kasih sebelumnya atas sarannya.

— Curtis
sumber

Bisakah Anda memberikan crashdump penuh? Gambar di atas memotong bagian yang menarik. Juga, apakah Anda memposting crashdump di lkml ? Namun, melihatnya lagi, ini adalah kernel yang cukup tua, apakah ada rencana untuk meningkatkan Debian ke rilis stabil saat ini?

— ckujau

Sayangnya, kami tidak memiliki crash dump. Saya telah menambahkannya ke daftar saya untuk mengkonfigurasi konsol serial dan / atau kdump. Sedangkan untuk kernel yang sudah tua, Proxmox menggunakan kernel OpenVZ yang merupakan cabang dari kernel mainstream. Jadi, begitu saya bisa membuat crash dumps berfungsi, saya akan menghubungi pengembang OpenVZ untuk bantuan. Terima kasih atas komentar Anda ... itu membantu saya diarahkan ke arah yang benar.

— Curtis

Sakelar macam apa?

— ETL

Masalah ini terjadi dengan 3 switch berbeda (satu dlink dan 2 cisco). Saya tidak memiliki nomor model pada dua sakelar sebelumnya, tetapi yang terbaru adalah Cisco SG102-24. Karena hanya memengaruhi server-server di sakelar yang menjalankan kernel yang sama, dan karena saya berada di sakelar ketiga saya, sepertinya sakelar itu tidak mungkin disalahkan (walaupun itu juga pemikiran awal saya).

— Curtis

Saya menerima pemberitahuan email bahwa seseorang memposting komentar berikut di sini ... "Saya memiliki masalah serupa kecuali bahwa saya dapat membuat tambang saya mogok dengan beberapa wadah melakukan hard core ..." Sayangnya, itu terputus di sana dan ketika saya datang di sini, penulis telah menghapus komentar mereka jadi saya tidak tahu apa sisanya. Tapi, saya akan menambahkan bahwa saya telah mencatat bahwa masalah itu tampaknya paling sering terjadi ketika ada lalu lintas jaringan yang berat (seperti ketika cadangan sedang berjalan). Mungkin komentar itu adalah "transfer jaringan hardcore"?

— Curtis

Jawaban:

Saya hampir yakin masalah Anda bukan disebabkan oleh satu faktor tunggal melainkan oleh kombinasi faktor. Apa faktor-faktor individu itu tidak pasti, tetapi kemungkinan besar satu faktor adalah antarmuka jaringan atau driver dan faktor lain ditemukan pada sakelar itu sendiri. Oleh karena itu sangat mungkin masalah hanya dapat direproduksi dengan merek switch khusus ini dikombinasikan dengan merek antarmuka jaringan tertentu.

Anda tampaknya pemicu untuk masalah ini adalah sesuatu terjadi pada satu server individual yang kemudian memiliki kepanikan kernel yang memiliki efek yang entah bagaimana berhasil menyebar melalui switch. Ini kedengarannya mungkin, tetapi saya akan mengatakan itu adalah tentang kemungkinannya, bahwa pemicunya ada di tempat lain.

Bisa jadi ada sesuatu yang terjadi pada switch atau antarmuka jaringan, yang secara bersamaan menyebabkan kepanikan kernel dan masalah tautan pada switch. Dengan kata lain, bahkan jika kernel tidak memiliki kepanikan kernel, pemicunya mungkin telah menurunkan konektivitas pada switch.

Kita harus bertanya, apa yang mungkin terjadi pada server individual, yang dapat memiliki efek ini pada server lain. Seharusnya tidak mungkin, jadi penjelasannya harus melibatkan cacat di suatu tempat dalam sistem.

Jika itu hanya tautan antara server yang mogok dan sakelar yang turun atau menjadi tidak stabil, maka itu tidak akan berpengaruh pada status tautan ke server lain. Jika ya, itu akan dianggap sebagai cacat pada sakelar. Dan dengan lalu lintas, server lain akan melihat lalu lintas sedikit lebih sedikit setelah server macet kehilangan konektivitas, yang tidak dapat menjelaskan mengapa mereka melihat masalah yang mereka lakukan.

Hal ini membuat saya percaya bahwa cacat desain pada sakelar mungkin terjadi.

Namun masalah tautan bukanlah penjelasan pertama yang akan dicari ketika mencoba menjelaskan bagaimana masalah pada satu server dapat menyebabkan masalah ke server lain di sakelar. Badai siaran akan menjadi penjelasan yang lebih jelas. Tetapi mungkinkah ada hubungan antara server yang mengalami kepanikan kernel dan badai penyiaran?

Multicast dan paket yang ditujukan untuk alamat MAC yang tidak diketahui lebih atau kurang diperlakukan sama dengan siaran, sehingga badai paket seperti itu akan dihitung juga. Mungkinkah server paniced mencoba mengirim crashdump di seluruh jaringan ke alamat MAC yang tidak dikenali oleh switch?

Jika itu pemicunya, maka ada sesuatu yang salah pada server lain. Karena paket badai seharusnya tidak menyebabkan kesalahan semacam ini pada antarmuka jaringan. Reset adapter unexpectedlytidak terdengar seperti paket badai (yang seharusnya hanya menyebabkan penurunan kinerja tetapi tidak ada kesalahan seperti itu), dan itu tidak terdengar seperti masalah tautan (yang seharusnya menghasilkan pesan tentang tautan turun, tetapi bukan kesalahan Anda melihat).

Jadi kemungkinan ada beberapa cacat pada antarmuka perangkat keras jaringan atau driver, yang dipicu oleh saklar.

Beberapa saran yang dapat memberikan petunjuk tambahan:

Dapatkah Anda menghubungkan beberapa peralatan lain ke sakelar dan melihat lalu lintas apa yang Anda lihat pada sakelar saat masalah muncul (saya perkirakan itu akan menjadi sunyi atau Anda melihat banjir).
Apakah mungkin untuk mengganti antarmuka jaringan di salah satu server dengan merek yang berbeda menggunakan driver yang berbeda untuk melihat bagaimana hasilnya ternyata berbeda?
Apakah mungkin untuk mengganti salah satu sakelar dengan merek lain? Saya berharap mengganti saklar akan memastikan masalah tidak lagi mempengaruhi beberapa server. Yang lebih menarik untuk diketahui adalah apakah hal itu juga menghentikan panik kernel.

— kasperd
sumber

Terima kasih atas balasan bijaksana Anda. Dalam hal 3 saran Anda: 1) Apa jenis peralatan / perangkat lunak yang akan melakukan itu? 2) Berharap saya bisa, tetapi ada banyak server yang terlibat dan saya tidak tahu di mana masalah akan terjadi selanjutnya. 3) Saya sudah mencoba 3 sakelar berbeda (3 model berbeda, 2 merek berbeda). Yang juga menarik adalah bahwa hanya server pada versi Proxmox yang sama yang terpengaruh. Proxmox memang memiliki mekanisme sinkronisasi klaster, jadi saya curiga ada hubungannya dengan itu. Untungnya, sudah beberapa bulan sejak masalah ini terjadi sekarang.

— Curtis

Untuk melihat lalu lintas di saklar saya berpikir menghubungkan PC biasa dengan tcpdump dan / atau wireshark. Tentunya Anda ingin menghindari menginstal perangkat lunak yang terpengaruh pada PC itu. Tapi sepertinya ada bug dalam kode yang diinstal oleh Proxmox ke dalam kernel. Jika itu terjadi sangat jarang, bahwa Anda hanya melihatnya sekitar sekali per bulan dan hanya pada satu saklar pada suatu waktu, maka mungkin butuh waktu lama untuk melacaknya. Saya akan memikirkannya sedikit dan berkomentar, jika lebih banyak ide muncul.

— kasperd

Kedengarannya bagi saya seperti bug di driver ethernet atau perangkat keras / firmware, ini menjadi bendera merah:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly

Saya telah melihat ini sebelumnya dan dapat mengetuk server offline. Saya tidak ingat persis apakah itu pada kartu ethernet intel tapi saya percaya begitu. Bahkan mungkin terkait dengan bug di kartu ethernet sendiri. Saya ingat pernah membaca sesuatu tentang kartu ethernet intel tertentu yang mengalami masalah seperti itu. Tapi saya kehilangan tautan artikel.

Saya akan membayangkan bahwa pemicunya untuk ini sebagian tergantung pada driver (versi) yang digunakan, fakta bahwa versi yang lebih lama dari perangkat lunak berfungsi dengan baik tampaknya mengonfirmasi hal itu. Anda mengatakan vendor menggunakan kernel kustom mereka sendiri, cobalah untuk memperbarui modul driver ethernet yang digunakan untuk perangkat keras ethernet Anda. Baik satu dari vendor Anda atau satu dari pohon sumber kernel resmi.

Lihat juga ikatan perangkat keras ethernet Anda, biasanya server akan memiliki dua port ethernet, onboard, dan / atau kartu tambahan. Dengan begitu jika satu kartu ethernet mengalami masalah ini, yang lain akan mengambilnya. Saya menggunakan kata "kartu" tetapi ini berlaku untuk perangkat keras ethernet apa saja.

Mengganti perangkat keras ethernet juga dapat memperbaikinya. Ganti atau tambahkan kartu ethernet (intel) yang lebih baru dan gunakan itu. Kemungkinannya adalah jika masalah ada di perangkat keras / firmware, kartu yang lebih baru memiliki perbaikan (atau lebih lama?).

— aseq
sumber

Mesin-mesin semua memang memiliki port ethernet ganda, namun, kesalahan ini terjadi di beberapa server sekaligus pada saat yang sama pada switch yang sama pada saat salah satu mesin terkunci. Pada saat server yang terkunci terkunci, semua server yang terkena dampak langsung dapat diakses kembali. Ini tampaknya menunjukkan bahwa server yang terkunci tidak sepenuhnya terkunci tetapi entah bagaimana membanjiri pengaturan ulang mesin pada sakelar yang sama. Akan menarik untuk melihat apakah pembaruan driver dapat membantu, tetapi saya tidak berpikir mengaktifkan kartu ethernet lainnya dapat membantu berdasarkan bukti.

— Curtis

Utas lama, tetapi bahkan dengan Intel e1000e NIC Model 82574L dan salah satu versi ProxMox yang lebih baru, 5.0-23 / af4267bf, masalah jaringan masih ada. Saya dapat membuka laptop windows saya (bangun dari tidur atau hanya login) yang terhubung ke switch yang sama dan server ProxMox melakukan reboot pada dasarnya setiap saat. Saya juga melihatnya hanya reboot secara sporadis ketika tidak terhubung ke switch. Dan itu akan reboot ketika saya pertama kali menghubungkannya ke saklar. Driver saat ini adalah 3.3.5.3 dan ada 3.3.5.10, 3.3.6 dan 3.4.0.2 jadi saya mungkin akan mencoba membangun dan menggunakan itu. .02c saya.

— JGlass