Menemukan masalah Hetzner dengan powerstat, sensors, dan dmidecode

Debugging Hetzner: memecahkan masalah dengan powerstat, sensors, dan dmidecode

• Latar belakang

  • Ubicloud mengadopsi server AX162 milik Hetzner, tetapi mengalami masalah keandalan yang serius.
  • Server AX162 menawarkan performa lebih baik dan harga lebih murah dibanding model sebelumnya, tetapi mengalami crash 16 kali lebih sering.
  • Masalah baru terselesaikan setelah beberapa pembaruan perangkat keras.

• Terjadinya masalah

  • Tiga minggu setelah pembelian server AX162 pertama, terjadi crash server.
  • Byte NULL ditemukan di log sistem, yang menandakan kegagalan mendadak seperti kehilangan daya.
  • Hetzner melakukan pemeriksaan perangkat keras, tetapi tidak menemukan kelainan.
  • Frekuensi crash meningkat, dan Hetzner mengganti server setiap kali menemukan cacat perangkat keras.

• Investigasi awal

  • Beban sistem: Awalnya diduga masalah lebih mungkin terjadi saat beban meningkat, tetapi crash juga terjadi saat beban rendah atau tidak ada.
  • Suhu: Suhu diukur menggunakan sensor, tetapi suhu pada saat crash tidak lebih tinggi dari rata-rata.
  • Komponen cacat: Informasi perangkat keras dikumpulkan dengan perintah dmidecode, tetapi tidak ada perbedaan besar antara server yang mengalami crash dan yang tidak.
  • Konsumsi daya: Konsumsi daya diukur dengan alat powerstat, dan muncul kecurigaan bahwa Hetzner mungkin membatasi penggunaan daya.

• Pengumpulan dan perbandingan data tingkat crash

  • Keandalan perangkat keras diukur menggunakan annual failure rate (AFR).
  • Server AX162 mengalami kegagalan 16 kali lebih sering dibanding model lain.
  • Setelah crash pertama, 80% server mengalami crash kedua dalam 24 jam.

• Mengamati stabilitas dengan perangkat keras baru

  • Hetzner mengonfirmasi adanya batch motherboard yang cacat dan merekomendasikan penggantian.
  • Bahkan setelah diganti dengan motherboard baru, crash tetap terjadi.
  • Setelah diganti dengan motherboard terbaru dan dipantau selama beberapa bulan, masalah crash terselesaikan.

• Perbaikan proses

  • Peninjauan yang menyeluruh diperlukan saat mengadopsi model server baru.
  • Perangkat keras baru sebaiknya diperkenalkan secara bertahap, dimulai dari pekerjaan nonkritis.
  • Menambah lebih banyak penyedia bare metal untuk menyebarkan risiko.

• Kesimpulan

  • Adopsi awal server Hetzner menimbulkan masalah, tetapi persoalan tersebut terselesaikan melalui perbaikan berkelanjutan.
  • Ubicloud akan terus berupaya menyediakan solusi cloud yang andal dan adaptif.

[GN⁺]

Komentar Hacker News

• Sebagian besar model AX lainnya (AX42, AX52, AX102) juga memiliki masalah keandalan serius yang rusak setelah beberapa bulan. Ini didasarkan pada motherboard yang cacat. Hetzner harus mengganti sebagian besar motherboard server yang diproduksi sebelum tanggal tertentu
• Di perusahaan sebelumnya, kegagalan kipas CPU sering ditemukan di Hetzner. Ini terjadi selain kegagalan HD/SSD yang umum. Pemantauan mandiri diperlukan, dan ini adalah salah satu alasan server yang tidak dikelola lebih murah daripada instance cloud
• Kalau melihat ke belakang, jika menunggu 6 bulan, banyak masalah bisa dihindari. Pengguna awal sering menemukan masalah yang diperbaiki kemudian
  • Ini nasihat yang sangat baik, dan saya mengikutinya untuk semua sistem yang membutuhkan stabilitas
  • Jika tidak ada masalah keamanan, saya menunggu beberapa bulan atau tetap satu-dua versi di belakang
• Hetzner tidak mengonfirmasi maupun menyangkal kemungkinan adanya pembatasan daya
  • Apa konsekuensi dari pembatasan daya? Menurut artikel, perangkat keras bisa mengalami degradasi lebih cepat
  • Kurangnya respons dari Hetzner dan pengukuran UbiCloud tampaknya menunjukkan bahwa mereka memang membatasi daya. Jika tidak, mereka pasti akan mengatakannya
• Dell juga kadang mengalami masalah ini. Saat menerima batch pertama server lama mereka, saya harus mengganti bagian I/O (belakang). Setelah memperbaiki masalah ini, server berjalan hampir 10 tahun
  • Baru-baru ini server-server itu dipensiunkan. Semuanya sudah aus, dari kartu RAID hingga pengatur daya
  • Pengalaman me-reboot server yang berfungsi sempurna karena perubahan konfigurasi lalu kehilangan kartu RAID selamanya itu mengejutkan
• Di bawah batasan daya, operator pusat data biasanya membatasi penggunaan daya per mesin untuk menambah jumlah mesin. Namun, ini bisa membuat motherboard mengalami degradasi lebih cepat
  • Adakah yang bisa menjelaskan ini? Ini terasa berlawanan dengan intuisi
  • Menurut hasil pencarian, jika terkena thermal throttling, suhu operasi yang tinggi dapat membuat komponen (misalnya kapasitor) lebih cepat rusak. Namun, artikel tersebut menyelidiki berbagai sensor suhu dan tampaknya itu tidak berlaku di sini
• Saya penasaran apakah ini bisa jadi masalah daya/sinyal atau masalah VRM. CPU yang tidak panas tidak berarti bagian lain pada board tidak keluar dari spesifikasi dan menyebabkan kegagalan fatal
  • Masalah motherboard terkait daya/sinyal sulit didiagnosis. Ini muncul sebagai masalah pada komponen lain, dan pada akhirnya Anda mengganti semuanya sebelum benar-benar mengganti motherboard
• Hal serupa juga terjadi pada AX102 yang sedang saya gunakan sekarang. Crash terjadi karena masalah yang berkaitan dengan kartu jaringan. Untungnya, dukungan Hetzner membantu penggantian perangkat keras. Ini menyebabkan banyak penderitaan, tetapi menjadi pelajaran bagus dalam memecahkan masalah perangkat keras
• Adakah yang punya pengalaman pusat data dan bisa menebak solusi komersial seperti apa yang mungkin dicapai Hetzner dengan pemasok motherboard? Bisakah diasumsikan semua motherboard diganti gratis dan mereka menerima kompensasi?
• Sebelum menduga ada pembatasan daya, saya ingin melihat governor CPU apa yang berjalan pada sistem tersebut. Banyak instalasi Linux default menjalankan governor hemat daya, yang membatasi frekuensi maksimum dan daya maksimum